Sunday, 17 July 2016

"I would walk 500 miles", that would be along a Great Circle, I presume...

Drawing Shapes on Maps


A while ago an image was doing the rounds on social media which showed a circle with radius of 500 miles centred on Leith, thereby depicting the possible search area covered by the Proclaimers in their (rather excellent ) "500 miles" .

As is often the case one sees with shapes drawn on maps, the circle was drawn as a pure geometric circle superimposed on a Mercator map projection. This is of course easy to do, but is misleading: strictly speaking, that pure shape suggests that all the radial lines would be Rhumb-lines (i.e., straight lines drawn on a Mercator projection). Although it looks like a circle, it really isn't: when drawn on the surface of a sphere (or more accurately, an ellipsoid) representing the Earth's 3D geometry, that simple Rhumb-line circle would be distorted. Instead, a circle drawn on the surface of the sphere (or ellipsoid) should be constructed from radial lines which are arcs of Great Circles rather than Rhumb-lines (note: such a circle, constructed from Great Circle arc radii, is actually called a Small Circle). The aforementioned distortion is greater for larger circles: but even at 500 miles radius, it is evident.

The image below illustrates the point. The two "500 mile circles" are depicted: the one constructed from Rhumb-lines (which actually looks like a circle on this Mercator projection map), the other from Great Circles (which is actually distorted on the map, but would look like a circle when viewed on the surface of an ellipsoid). Both are centred on Leith (near Edinburgh, Scotland). Since distances aren't preserved under projection, I have (arbitrarily) set the northern-most point of each circle to be in the same location (at 500 miles along a Great Circle from Leith). All other points on the two shapes are different. In terms of perimeters and areas, the Rhumb-line derived circular shape is larger: perimeter 5,639 km; area 254,3000 sq-km, versus perimeter 5,038 km; area 202,8000 sq-km for the Great Circle derived shape. So, assuming The Proclaimers walk along Great Circles in their quest, they will cover a smaller area of land than if they simply drew a circle on a map and used that to navigate.



#RSMM

I've used this "500 miles" example to demonstrate the (new) Shapes functionality I've just released within my #RSMM (#ReallySimpleMovingMap) web-app.

Here's the #RSMM link containing the "500 miles"  example. Click on it to go the #RSMM web-app. From there, you can experiment with lots of different shapes (not just circles!)

Here is a summary of the Shapes functionality within #RSMM:
  • Create shapes and display them on the map. Available shapes include:
    • point
    • line (arbitrary number of vertices)
    • circle and circular arc (portion of circle)
    • square
    • rectangle
    • triangle
    • polygon (arbitrary number of vertices)
  • The shapes can be specified as being constructed from either Great-Circle segments (on a reference Ellipsoid), or from Rhumb-line segments (i.e., straight lines on Mercator projections)
  • For convenience, the shape coordinates are initialised via Marker locations, and then can be fine-tuned via edit-boxes
  • All visual attributes of the shapes can be customised e.g., line color & opacity, line thickness, fill colour & opacity, etc.
  • Save the shapes (individually or in groups) to the FlyLogical Cloud (database) for convenient re-use later (and for sharing with the public if desired)
  • Export the shapes (individually or in groups)  to KML file format (sent by email) for ease-of-use with KML-supporting apps such as GoogleEarth.
Enjoy!

Tuesday, 5 April 2016

"Mags Off" -- or are they ?

Following recent magneto trouble (see my previous post on this), with both magnetos removed from the aircraft, I decided it was a good opportunity to check the function of the ignition switch (see photo below) on my Bulldog.


The entire functionality of the ignition switch depends on the "p-leads" which connect the ignition switch to the primary coils (hence the "p") of the left and right magneto, respectively. In a nutshell, a given magneto can be effectively disabled (i.e., "switched off" such that it will not generate a voltage in the spark-plugs) by grounding its primary coil against the magneto housing (thereby preventing a high voltage to be induced in the secondary coil when the points open).

The ignition switch has three connectors (terminals) on its back-plate: "L" -- which is connected by insulated wire to the "p-lead" of the Left magneto;  "R" -- which is connected by insulated wire to the "p-lead" of the Right magneto;  and "GND" -- which is connected by separate insulated wires to the metal housings of each magneto. These "GND" wires ensure that a solid, definitive grounding is achieved in the magnetos, without having to reply on the general airframe grounding.

First things first -- check the wiring, especially the insulation and the terminal connectors


If there are any problems with the integrity of the aforementioned wiring, the operability of the ignition switch and the magnetos can be adversely affected. Therefore, the first thing to check is to verify that the wires are in good condition. Importantly, the insulation must not be cracked (which can cause inadvertent grounding -- and disabling of the magneto); and the terminal connectors (crimped "eyelets") must be firmly connected to the wires (otherwise the grounding can fail, and the magnetos will remain live, irrespective of the switch position).

How the ignition switch is meant to work


The following table summaries how the ignition switch is intended to function

Ignition Switch position Function Effect
OffCompletes (closes) circuits between Left mag "p-lead" and ground, and between Right mag "p-lead" and GND (ground)Both magnetos disabled ("switched off"), spark-plugs cannot fire, engine cannot run
RCompletes (closes) circuit between Left mag "p-lead" and GND (ground); but breaks (opens) circuit between Right mag "p-lead" and GND (ground)Left magneto disabled ("switched off"); right magneto enabled ("switched on"), spark-plugs (from right magneto only) can fire, engine can run
LCompletes (closes) circuit between Right mag "p-lead" and GND (ground); but breaks (opens) circuit between Left mag "p-lead" and GND (ground)Right magneto disabled ("switched off"); left magneto enabled ("switched on"), spark-plugs (from left magneto only) can fire, engine can run. Also, engine can be easily started via the (relatively slow) rotation produced by the starter motor since left magneto incorporates an impulse-coupler to amplify the effect of slow rotation.
BothBreaks (opens) circuits between Left mag "p-lead" and GND (ground), and between Right mag "p-lead" and GND (ground)Both magnetos enabled ("switched on"), spark-plugs (from both magnetos) can fire, engine can run.


How to test the ignition switch


Given the expected operation summarised in the table above, it is straightforward to test the ignition switch using an electrical circuit continuity-tester. Most digital multi-meters have such functionality built-in, with an audio setting/mode which makes testing particularly easy: the device emits a steady tone when the circuit between the test probes is complete (resistance approaching zero); and is silent when the circuit is broken (resistance approaching infinity).

In order to perform the tests, the "p-leads" must be disconnected from the magnetos, otherwise the primary coils can be grounded (via the closed breaker points), ignoring any effect of the ignition switch. It is very important to make sure that the aircraft is made safe before performing the tests since as soon as the "p-leads" have been disconnected, the magnetos are live, irrespective of the ignition switch position. The aircraft can be made safe by disconnecting all high tension leads from the spark-plugs. Alternatively, the magnetos can be removed from the aircraft.

Once the aircraft has been made safe, the ignition switch can be tested as follows:

  1. Disconnect the "p-lead" from the magneto-under-test
  2. Connect a continuity tester between the "p-lead" wire (coming from the ignition switch) to the GND wire (coming from the ignition switch). The photo below demonstrates the test configuration on the wires for the left magneto of my Bulldog (note: the magneto has been removed from the aircraft).

  3. Test configuration for checking electrical continuity between magneto "p-lead" (red crocodile clip) and GND (ground) wires (black crocodile clip). The audio mode/setting has been selected on the multimeter such that a steady tone is emitted when the circuit is complete, and is silent when the circuit is broken. The aircraft has been made safe by removing both magnetos before conducting the tests. After testing the left magneto wires, the similar test configuration is applied to the right magneto wires, in turn. 


  4.  Test each position of the ignition switch, in accordance with the following tables for Left magneto, and Right magneto, respectively.

  5. LEFT MAGNETO SWITCH TESTING SEQUENCE
    Ignition Switch positionExpected test resultActual test result (from my Bulldog)
    OffCircuit should be closed between Left mag "p-lead" and ground, steady audible tone from meterIntermittent audio tone from meter, affected by wiggling of the knob; silent when knob released, meaning Left magneto would actually be "on" instead of "off", even though switch is in Off position
    RCircuit should be closed between Left mag "p-lead" and ground, steady audible tone from meterAs expected, steady audible tone, Left magneto disabled
    LCircuit should be open between Left mag "p-lead" and GND (ground), silence from meterAs expected, silence from meter, Left magneto enabled
    BothCircuit should be open between Left mag "p-lead" and GND (ground), silence from meterAs expected, silence from meter, Left magneto enabled

    RIGHT MAGNETO SWITCH TESTING SEQUENCE
    Ignition Switch positionExpected test resultActual test result (from my Bulldog)
    OffCircuit should be closed between Right mag "p-lead" and ground, steady audible tone from meterIntermittent audio tone from meter, affected by wiggling of the knob; silent when knob released, meaning Right magneto would actually be "on" instead of "off", even though switch is in Off position
    RCircuit should be open between Right mag "p-lead" and GND (ground), silence from meterAs expected, silence from meter, Right magneto enabled
    LCircuit should be closed between Right mag "p-lead" and ground, steady audible tone from meterAs expected, steady audible tone, Right magneto disabled
    BothCircuit should be open between Right mag "p-lead" and GND (ground), silence from meterAs expected, silence from meter, Right magneto enabled


Implications of test results


On a positive note, under all conditions which would ordinarily be encountered in flight, the ignition switch had the desired and expected effect (as highlighted in green in the tables above): namely, the magnetos are "live" when they are expected to be live.

However, in the one condition which would not ordinarily be encountered in flight, namely, with the ignition switch in the "Off" position, the effect of the switch was not as expected (as highlighted in red in the tables above): namely, both of  the magnetos are, in fact, "live" when they are intended to be "off". This has obvious safety implications for anyone in proximity of the aircraft when it is on the ground  (e.g., parked in the back of the hangar): if the propeller happens to be turned by hand, the engine could fire. I know I am not the only one who routinely hand-turns the propeller when the ignition switch is "Off": I do it every time I take the aircraft out of the hangar, or put it back in again. I need to turn the propeller "horizontal", out of the way of the mechanical tug I use to move the aircraft on the ground.

What about the "dead-cut" check ?


This check (i.e., momentarily switching the ignition to "Off" while the engine is running on the ground, the point being to verify that indeed the magnetos are no longer live). Some pilots perform this check after every flight. As a rule, I do not since such a check was not part of the RAF checklist for the Bulldog (and that is where I learned to fly, old habits die hard, etc). Also, over the years since, I have been led to believe such a check can actually damage the engine (by causing explosions in the exhaust system ??) --possibly an urban myth, but one that has stuck with me.

In any case, given the precise nature of this failure, it is not clear that a dead-cut check would have actually revealed the problem. Reason: as I noted in the table above, the test suggested intermittent electrical contact when the switch was in the "Off" position. In more detail, what actually happened was that when I wiggled the knob, applying positive pressure with my hand, the circuit would in fact close (on both magnetos), disabling them as intended. However, when in the mechanically-relaxed condition (hand off the knob), the lack of positive pressure would cause the circuits to break (and the magnetos to go live). Since the conventional method of performing the dead-cut check is to momentarily flick the switch to "Off" then back to "Both" again, with one's hand never leaving the knob, manual pressure is constantly applied, and the mechanically-relaxed condition (when the failure actually occurs) is never met throughout the check.

To be clear, there is a check described in Mandatory Airworthiness Directive Bendix AD 76-07-12 (30 August 1977[SB-583]), which must be carried out every 100 hours. The wording therein states "With the engine at normal idle, rotate the switch key or lever through the "OFF" detent to the extreme limit of its travel in the "OFF" direction.". However, in my experience on my aircraft at least, at the behest of the engineer during (typically) the annual inspection, this check has always been carried out by myself (as pilot, which is permitted in accordance with the AD), via the approach for the dead-cut check i.e., momentarily switching to "Off" without taking my hand off the knob. As described above, this does not guarantee that the switch is working correctly.

At the very least, in order to be sure that "Off" means "Off", I therefore suggest that the dead-cut check should be done by actually taking one's hand off the knob when it is in the "Off" position, and verifying that the engine dies (or definitively starts to die, before being recovered by switching the knob before the engine actually stops).

What can be done ?


In accordance with my mantra of "always replace worn parts" (in spite of the fact that this very policy resulted in me recently experiencing a total failure of the right magneto, owing to an assembly defect in the new magneto, see previous post), I went ahead and had the ignition switch replaced with new (see photo below)...Nevertheless, just to be sure that the issue was not due to bad wiring, I did have the tests described above performed all over again on the new switch once installed. Everything functioned as intended, and the issue has therefore been fully resolved on my aircraft.


New ignition switch which fully resolved the problem (Bulldog Part Number BH-81-461 which is actually a Bendix USA component with a BAe label affixed. The Bendix identification engraved on the casing is: 10-357290-1 C 8150)

What about refurbishing the old switch ?


The message here is positive. It turns out that the ignition switch is actually quite a simple electro-mechanical device comprising a pair of spring-loaded metal riders which rotate across metal and/or plastic surfaces to either make or break the circuit (metal-to-metal to complete the circuit when grounding the magneto, and metal-to-plastic to open the circuit, making the magneto live, depending on switch position; one half-track for the left magneto, the other half for the right). Apart from the metal strip contacts, there are no electrical/electronic/circuit components whatsoever inside the switch.

The photo below shows the old switch, opened-up. Although not wholly apparent from the photograph, the track contact surfaces (as well as the metal riders, shown at the bottom of the picture) were covered in "gunk". No too surprising, I suppose, after possibly forty years of service without (I bet) ever being cleaned. After thoroughly cleaning the innards of the switch, reassembling, and re-testing, it worked flawlessly. It is a simple and robust device, and was restored to full functionality with ease. This refurbished switch would of course require authorised approval before installing in a certified aircraft.


View inside the ignition switch which was exhibiting the failure whereby electrical contact was not being made when it should have been, thereby not grounding either of the magnetos when the switch was in the "Off" position (when the magnetos' primary coils should have been grounded). After a thorough cleaning of the insides of the unit, and re-testing, the switch performed as expected, thereby solving the problem in principle (but would, of course, require authorised approval before installing on a certified aircraft).

Note: this procedure for cleaning the switch is in direct accordance with the manufacturer's documentation, available here. Also described therein is a test procedure materially the same as described above.



Lessons learned


Here's what I've learned from this experience:

  1. Magnetos may not be off even when the ignition switch is in the "Off" position
  2. The "dead-cut" check should include taking one's hand off the knob when in the "Off" position to verify that the engine indeed (starts to) die.
  3. Despite 10 successive annual inspections and 3 "star annuals" since I've owned the aircraft (my aircraft is operated on a UK CAA C-of-A and associated maintenance regime), I conclude that the operation of the ignition switch was never adequately tested. I did find a test description similar to the one I've outlined here in the Bulldog T Mk 1 Aircraft Servicing Manual -- AP101B-3801-1 (Vol 2 Chapter 40-3 p11 section 2.3.9 "Do a continuity check...") within the list of side-tasks pertaining to magneto timing, but I suspect that maintenance regime has not been followed: instead, it is my understanding that engineers tend to follow the generic CAA LAMS inspection regime where the only entry pertaining to magnetos (that I could find) is as follows: "Ignition: Task No 66: Magnetos, harnesses, leads, switches, starting vibrators, contact breakers, cooling system and ventilators: INSP 150 FH". Although "switches" are generically mentioned therein, I am unaware of any detailed, focused tests actually being performed under this task.
  4. Given point 2) above, I recommend that if your aircraft has the same or similar kind of ignition switch as my Bulldog, you get your ignition switch tested as soon as possible -- and certainly before you (or anyone else) hand-turn the propeller even with the ignition switch in the "Off" position. The test is straightforward (requiring just a continuity-tester), and so is the rectification if problems are found (thoroughly cleaning the switch inside, or replace it). For piece of mind, I would also propose repeating the test whenever practically convenient (e.g., when the magnetos are removed for overhaul, etc).
  5. Even though I know my own aircraft is now safe in this regard, this experience means I cannot trust that any other aircraft sitting there with the "mags off" is actually safe. It reinforces what was possibly the first lesson in airmanship that I was ever given: "never put any part of your body within the arc of any propeller,  as you should consider that the engine could fire at any time!"







Friday, 2 October 2015

Loving my new HiFi

It's not what you think: I'm talking about WiFi in my Hangar-- hence HiFi

I needed to get broadband into my hangar at EGNS (Ronaldsway Airport, Isle of Man) and there was no possibility of installing a landline (for ADSL etc). Here's my solution which you may find helpful if faced with a similar challenge:

1) Purchased 4G mobile broadband data-only subscription package from local provider

2) The provider in 1) issued me with a MiFi box: specifically a D-Link DWR-921 router (like this)

3) The router in 2) was easy to set up, but the signal was poor inside the hanger.

4) So I replaced the little paddle antennas provided with the router (see the "paddles" in the pictures at previous link)  with an external antenna, specifically this one.

5) I mounted the antenna on the hangar roof (see photo below). The cables attach directly to the terminals of the router, no extra adapters required.

6) I now routinely get 28 MBPS downlink and 10 MBPS uplink, with no dropouts. Without the external the antenna, performance was a few MBPS downlink at best, and frequent dropouts.

Job done.


External antenna mounted on hangar roof provides adequate boost for 4G broadband reception inside the hangar





 

Thursday, 24 September 2015

New magneto failure after just 15 flying hours

Updated 4 October 2015 with result from inspection of left magneto

My recent experience, described here, is quite shocking (pun intended)!

After a pleasant flight around the Isle of Man in my Bulldog last weekend, I discovered (to my horror) when performing the pre-shutdown checks that my right magneto was completely dead (instead of RPM dropping a bit, the engine simply stopped when selecting "R" on the ignition knob). Somewhat strangely, I noticed no loss of performance during the flight. Before take-off, the engine run-ups were nominal (both magnetos working as expected, within the allowable limits of "max drop 175, max difference of 50" when switching between "L", "R" and "Both").

This shouldn't happen to a new magneto!


The magneto in question was replaced less than six months ago, during the aircraft's annual inspection.  Rather than have both (left and right) overhauled (which happened to be due), I opted to have them replaced with new. By "new", this actually meant "factory rebuilt", the only option available for these types. Being based on an island, with a water-crossing (of some degree) on almost every flight, in the interests of safety, I prefer to renew key components rather than have them overhauled. I had flown the aircraft just under 15 hours before the magneto failure last weekend.

So what happened ?


Back in the hangar, having made the aircraft safe (by removing all spark-plug leads, and removing a spark-plug from each cylinder -- to make it easy to hand-turn the engine), I hooked-up the E50 timing synchroniser to the magneto, hand-turned the prop through a few cycles, and watched the lights on the E50 remain steady (instead of sequencing on-and-off as the points opened). This gave a strong clue that the magneto had failed. Just to be sure, I disconnected the "p-lead" and performed the test again: same result, lights stayed on (this latter test verifying that it was indeed a magneto fault and not some fault with the "p-lead" safety cable).

Next step was to remove the magneto and send it back to the engine shop. They quickly diagnosed the issue, described as follows:

"Due to an assembly error, the internal cable leading from the coil was too long, and was routed too close to the rotor. They came into contact, and the spinning rotor wore through the cable insulation and shorted the coil (see attached photos). The resulting heat dried out the bearings. Best to get a replacement magneto under warranty from the factory, rathe​r than repairing this one...and check the left magneto, since it was built around the same time as this one!"


Note the frayed insulator in contact with the rotor




Lessons learned 


Here's what I've learned from this experience:

  • New components can fail
  • Always perform every check in the checklist (I'm fortunate: the RAF drilled that discipline into my head). Each and every check is included on the list for a reason.
  • It is extremely useful to have two magnetos rather than one, especially when flying over the sea!
  • This type of thing doesn't just happen to someone else...

What's next ?


  • When the replacement unit arrives from the factory, I'll ask the engine shop to visually inspect that cable before sending the magneto out for fitting to the aircraft
  • The engine shop will submit a report to the manufacturer based on their findings. Given the seriousness of this incident, I would expect that there will be some sort of action mandated by the manufacturer regarding these magnetos. Maybe the issue pertains to just a specific batch, or maybe to all of that type, or even to all from that manufacturer...
  • So, if you have TCM/Bendix 1200 SERIES magnetos on your aircraft, don't be surprised if a Mandatory Service Bulletin appears pertaining to this issue...and even if no such bulletin appears, I recommend you have your magnetos checked just to be sure. 


What about the left magneto ?

Update 4 October 2015


Just to be sure, since it was replaced at the same time as the faulty right magneto, I had the left magneto removed and inspected. It got the "all clear". As can be seen in the photograph below, the cable lies well clear of the rotor, as it should.

Left magneto inspection (just to be sure, since replaced at same time as the faulty right magneto): observe that the cable is lying in the correct manner, well clear of the rotor.


Friday, 4 September 2015

Automated daily MET and NOTAM briefings via Twitter

For greater convenience for iNavCalc Twitter App users, I've recently added an automatic briefing function for METAR/TAFS and NOTAMS. Basically, the twitter.com/@FlyLogical feed now publishes a METAR/TAF briefing every four hours, and a NOTAM briefing once per day. The list of stations used in these briefings can be added to by any registered FlyLogical.

Instructions here

Enjoy.

Thursday, 21 May 2015

#BULLCHIPMEET2015

Just returned from a fun trip to Abbeville, France (LFOI), where I attended #BULLCHIPMEET2015, a annual gathering of fellow Bulldog and Chipmunk enthusiasts. The focus of the event is formation flying. Here are some videos from the cockpit of my Bulldog taken during the event:

Videos



...and here's the route I took to get there...


Saturday, 11 April 2015

Announcing #TweetiNavCalc Web App

UPDATED 4 September 2015 to include automated daily briefings

I've just made it easier for anyone interested in viewing and sharing METAR/TAFs, NOTAMs, and Route (Google) Maps on Twitter. Basically, I've built a simple web-app wrapper around the existing iNavCalc Twitter App. The wrapper does most of the work for you. You can find the app here, and it looks like the screenshot below (usage self-explanatory, especially if you've read this):



Saturday, 7 March 2015

Global Aviation Database in GoogleDocs

As an exercise in GoogleDocs API programming, I've published a "data dump" from the FlyLogical database in GoogleDocs Spreadsheet format.


The spreadsheet contains all global airports and navaids currently stored in the FlyLogical database (and as used by the iNavCalc and Really-Simple-Moving-Map suite of apps).

The spreadsheet will be updated automatically (every week or so) via the openAIP crowd-sourced data sets. See my previous post for more on this aspect.

Hope you find the database/spreadsheet interesting and possibly even useful !

Thursday, 19 February 2015

FlyLogical embraces openAIP

I'm pleased to announce that I have recently hooked-up with openAIP.net to provide weekly automated updates to the iNavCalc airport COMMS FREQUENCIES database.

openAIP.net is a free, crowd-sourced resource for global aviation data. I encourage you to register and start contributing.

I was first put on to openAIP.net a couple of months ago by a FlyLogical user who suggested it might be a useful resource to incorporate into iNavCalc.  I wholeheartedly agree, not least since the "official" bodies don't seem to be able to provide such (see my previous rant on the subject), and because the openAIP.net team make it straightforward to consume their global data, from a "machine-to-machine" perspective.

For now, I have only implemented global airport COMMS FREQUENCY automated updates. In future, I will extend to NAVAIDS. Also, the "machine-to-machine" updates lag the openAIP.net website by a number of days, so do not expect to find openAIP.net website updates propagated immediately to iNavCalc. Instead, you will have to wait a week or so for the catchup to occur.

Many thanks to openAIP.net for providing this resource.

Thursday, 22 January 2015

Solar Impulse Route Calculations

Given that the Solar Impulse team published their round-the-world route overview yesterday, I thought it would be interesting to perform some basic navigation calculations based on that.

To start with, taking the proposed route overview, choosing relevant airports, filling in the blanks ("Kansas City airport" for "mid USA", and "Marbella airport" for "South Europe, North Africa"), gives the following approximate route in Google Maps, Really-Simple-Moving-Map, and SkyVector.

Distance and Time calculations


The total flight distance is 18,814 nautical miles, with a nominal (zero wind) total flight time of 27.5 days to be flown in sections over a few months from late-February/early-March 2015, to late-July/early-August, 2015. The following table summarises the distance along each leg in the route (assuming great circles), and the time taken to fly each leg assuming an airspeed of 35 mph (30.4 knots, 55.6 kph), derived from Solar Impulse 2's performance (which I simply found on the internet, as the published average ground-speed: is there perhaps a more accurate indicated airspeed I could use ?).  Times are given for zero-wind, 10 knot tailwind, and 10 knot headwind, respectively. This gives an idea of the (significant) effect of (moderate) wind on the performance, given the relatively low airspeed compared with conventional powered aircraft. A wind-speed of 10 knots at the cruising altitude of 5,500 feet would be considered as not atypical.   

Of particular note (highlighted in the table) is the longest leg of 4408 nm, across the Pacific from Nanjing (China) to Hawaii. Nominally (in zero wind), this would take 6 days, or 9 days in a 10 knot headwind, or 4 days 13 hours in a 10 knot tailwind. Many of the other legs also exceed one day, so the solar cells will need to be able to charge the batteries as well as keep the aircraft flying during the day, and the batteries will need to provide sufficient power to keep flying through the night, multiple times in the mission.

Leg Distance (nautical miles) Time (zero wind) Time (10kt tailwind) Time (10kt headwind)
1. Abu Dhabi (UAE) to Muscat (Oman) 206 6h:47m 5h:6m 10h:6m
2. Muscat to Ahmenebad (India) 791 1d:2hr:1m 19h:35m 1d:14h:47m
3. Ahmenebad to Varanasi (India) 578 19h:1m 14h:18m 1d:4h:20m
4. Varanasi to Mandalay (Burma) 757 1d:0h:54m 18h:44m 1d:13h:7m
5. Mandalay to Chongqing (China) 717 23h:35m 17h:45m 1d:11h:9m
6. Chongqing to Nanjing (China) 659 21h:41m 16h:19m 1d:8h:18m
7. Nanjing to Hawaii (US) 4408 6d:1h:0m 4d:13h:7m 9d:0h:5m
8. Hawaii to Phoenix (US) 2532 3d:11h:17m 2d:14h:40m 5d:4hr:7m
9. Phoenix to Kansas City (US) 905 1d:5hr:46m 22h:21m 1d:20h:22m
10. Kansas City to New York City (US) 964 1d:7h:43m 23h:52m 1d:23h:15m
11. New York City to Marbella (Spain) 3155 4d:7h:47m 3d:6h:6m 6d:10h:39m
12. Marbella to Abu Dhabi 3121 4d:6h:40m 3d:5h:15m 6d:9h:0m


Follow the Sun


Sunlight is, of course,  the key to Solar Impulses's success. You can use the SunDial function within Really-Simple-Moving-Map to see just how much sunlight Solar Impulse can expect at each point along the route.

For example, here's the Sun track for the starting point in Abu Dhabi, computed for the day I'm writing this post (22 Jan 2015). 





Challenging


This challenge represents an extremely impressive combination of engineering, technical, and human achievement. Very best of luck to the Solar Impulse team. I look forward to following their progress in the coming weeks, and hope they manage to break that next set of world-records in their sights.

Record-Breaking


...and talking of record-breaking, whilst warming-up in Abu Dhabi, I recommend they try the Formula Rossa roller-coaster, the fastest in the world...had a go at New Year. Breath-taking.




Sunday, 17 August 2014

Modelling the #Indyref outcome probabilities

Given the latest poll-of-poll results (courtesy of @WhatScotsThink on Twitter) and the betting exchange implied probabilities (courtesy of @neiledwardlovat on Twitter) pertaining to the upcoming Scottish Independence Referendum, I thought it would be interesting to combine these sources of information into (approximate) probability density functions for YES and for NO, respectively.

Meaningful criteria for the approximate probability distributions


In advance of the actual referendum on 18 September 2014 (which will settle the matter once and for all), assume that the proportion of voters who will vote YES can be modelled as a random variable, denoted Y. Likewise, for the proportion of voters who will vote NO, denoted N. Although the true probability density functions for these random variables are fundamentally unknown, meaningful estimates of the distributions can be derived given that they should reasonably satisfy the following criteria:

  • The Expected Value (approximated by the Mean or Average) of the given distribution should reflect the result of the aggregate of all the official polls conducted to date. Note: this criterion is only justifiable if the polls can be considered as truly representative of the actual full voting population. This is, of course, a highly debatable assertion, one extreme view being that "opinion polls are meaningless". But for the sake of current argument, the assertion that the polls are indeed representative, will be considered as valid.
  • The integral of the distribution (or "area under the probability density function" or "cumulative density function (cdf)") evaluated over the range from 0.5 to 1 (50% to 100%) should correspond to the implied probabilities ("chance of YES winning", and "chance of NO winning", respectively) from the betting exchange data. It could be viewed that this is a considerably less justifiable criterion than the previous, but on the basis that "the bookies are seldom wrong", it seems like quite a reasonable assertion. After all, the betting exchange data is "crowd-sourced" in that it reflects the combined "beliefs" of many thousands of punters, i.e.,  potential voters. Also, there is no other readily available source of such information, with the exception of the polling data itself (utilised in the previous criterion). However, modelling probability distributions on just the polling data would lead to much narrower distributions (i.e., suggesting considerably less uncertainty) than implied from the betting exchange data. Or put another way, the betting exchange data in effect incorporates the (potentially real) broader uncertainties than captured in the polling data alone. 

The Beta Distribution


Since the probability distributions for Y and N are fundamentally unknown, we are free to build models which meet the criteria presented above. A good candidate is the Beta Distribution which is often used for the purpose at hand, i.e., to devise a meaningful probability distribution for election outcomes involving two choices. One of the benefits of using the Beta Distribution  is that it is formally (structurally) similar to the Binomial Distribution which is widely used for modelling polling results. Taken together, these two distributions can be combined via Bayesian Inference to provide an updated-distribution-after-most-recent-poll which, is itself a Beta Distribution. This useful and interesting aspect will not be pursued at present. 

The Beta Distribution has two parameters, denoted A ("alpha") and B ("beta"). The numerical size of these determines the sharpness/certainty (or broadness/uncertainty) with large numerical values representing narrow distributions (i.e., with more certainty), and smaller numerical values representing broad distributions (i.e., with more uncertainty). Also, if A and B are numerically equal, the distribution is symmetric about a Mean value of 0.5 (50%). Unequal values for  A and B allow for skewed (non-symmetric) distributions with Mean values different from 0.5.

By trial-and-error, it is straightforward to determine the parameters (A, B) for the Beta Distributions which satisfy the criteria described earlier for both YES and NO. The results of these parameterisations are presented in the distributions below.

Probability Density Function (pdf) for YES


Probability Density Function (pdf) of a Beta Distribution parameterised (with A=21, B=27.89) to represent the random variable Y (or YES) based on polling data and betting exchange data as of 17 August 2014.  The Mean of the distribution (indicated by the dotted vertical line) is 0.43 corresponding to the poll-of-polls data which suggests that 43% will vote YES. The cumulative density evaluated from 0.5 to 1 (i.e., the area of the blue shaded region)  representing the probability that Y will exceed 0.5 i.e., that YES will win, is 0.15  in accordance with the 15% implied probability from the betting exchange data.

Probability Density Function (pdf) for NO


Probability Density Function (pdf) of a Beta Distribution parameterised (with A=30.3, B=22.81) to represent the random variable N (or NO) based on polling data and betting exchange data as of 17 August 2014.  The Mean of the distribution (indicated by the dotted vertical line) is 0.57 corresponding to the poll-of-polls data which suggests that 57% will vote NO. The cumulative density evaluated from 0.5 to 1 (i.e., the area of the blue shaded region)  representing the probability that N will exceed 0.5 i.e., that NO will win, is 0.86  in accordance with the 86% implied probability from the betting exchange data.

What are these good for ?


I would suggest that these approximate distributions, derived in accordance with the criteria presented, might be useful for anybody interested in exploring the statistics of #Indyref.  For example, if you are inclined to build a Bayesian Inference model for monitoring how the probabilities evolve following successive polls in the days leading up to 18 September 2014, these distributions might serve as usable "priors". Then again, all must be taken with a (large?) pinch of salt, since the assumptions and data used for deriving the distributions, by their very nature, may turn out to be non-valid :-)

Thursday, 24 July 2014

iNavCalc and Bulldog-Weight-and-Balance for Fire Phone

Delighted to announce that my free apps iNavCalc and Bulldog-Weight-and-Balance have just been approved by Amazon for their newly announced Kindle Fire Phone, giving you even more choice of platforms

Saturday, 19 July 2014

Get METARs and TAFs nearest to me or anywhere!

How often do you find yourself wondering what the aviation weather reports (METARs and TAFs)  look like nearest to your current location ? Or nearest to any other location you happen to be interested in ?

Really-Simple-Moving-Map (RSMM) gives you the answer to both with one click. Simply click on the RSMM map at either your current location or anywhere else (in the world!). The popup window contains, amongst other things, METAR & TAF briefings for the nearest reporting stations, ordered by closest first. You can adjust (via Options->Info on Marker Popups) the number of stations to report and whether or not to include decoded as well as raw briefings.

A detailed RSMM Users' Guide can be found here.

[Note: to enable the METAR & TAF functionality, you need to be a registered user. Registration is FREE].

Sunday, 1 June 2014

Chasing the Sun

For some reason, I've always been interested in the geometrical details of how the Sun tracks across the Earth for a given location and season. Some years ago I wrote the software which calculates all of this. [Users of iNavCalc may recognise the output of this effort in terms of the Sun angle calculations presented along a given flight route].

Considering that this topic may be of wider interest beyond pilots and #avgeeks, I've now built the functionality into #reallysimplemovingmap. Simply click anywhere on the map (or on any existing Marker). The usual Marker Info window will open:


You will see there is a (new) Sundial link. Click on this to open the Sundial window:

  
...which shows the  track of the Sun across the sky today for the selected location. The highlighted value corresponds to the position of the Sun right now (i.e., at the point in time when the Sundial link was clicked). Clicking anywhere on the trajectory shows the Sun position at that point on the trajectory (in terms of time, direction --true and magnetic, & height above horizon).

Hope you find it as fun and useful as I do. It is interesting to explore the polar regions, especially those in perpetual light or darkness. Fond memories of a fishing expedition to Alaska one August, when the Sun never set.





Sunday, 11 May 2014

Announcing Really Simple Moving Map

Over the past few months with my aircraft grounded (during it's C-of-A renewal, now done, thankfully !) and with the weather basically rubbish (around the UK) , I took the opportunity to explore the world of HTML5 cross-platform web-app programming.

As a "test app", I chose to put  together a "moving map", inspired by my interest in aviation and navigation, but also because the available mapping & navigation apps on Android, iOS etc never quite seemed to do what I want.

The first step was to select a mapping technology. One thing that became apparent early in the development was that I couldn't use GoogleMaps for this: the licensing from Google forbids the use of the GoogleMaps API for "real time" navigation applications. This was initially disappointing because I'd built up a fair working knowledge of the GoogleMaps API (as used in iNavCalc). However, in the end I'm grateful for the forced change: it led me to discover OpenStreetMap and leaflet.js , two open-source resources which are a delight to work with, and, moreover,  have none of the licensing restrictions of GoogleMaps.

I should emphasise that my goal was not to substitute my assorted "real" navigation devices with this "toy" web app. The limitations of web-technology preclude the use of such a web app for serious navigation -- not least since much of navigation takes place where there is no internet connection. Web apps -- by definition -- require a more or less continuous internet connection to function in their full glory, this one no exception.

That said, as I've been putting the app together and "field testing" it, I've been surprised how well it works in unlikely places e.g., hiking in the local hills (on the Isle of Man), skiing in Norway, sitting on airliners etc.. Of course, on the airliners, it only works until the 3G/4G/WiFi signal falls away, typically a few hundred feet into the air. I've also tried the app using the on-board WiFi signal that many airlines now offer. No joy -- not surprising, really, since the location services require triangulation i.e., more than one transmitter, and so the single WiFi hotspot on-board doesn't suffice.

On the subject of flying, I've not yet tried my new app "in the cockpit", so to speak. But now that I've got my C-of-A renewed, and the sun is shining, I'll give it a go. Of course the web-specific features won't work (since there's no reliable internet connection aloft), but with a bluetooth GPS receiver paired with my Android phone, the core location services of the app should be operable. I'll  post my observations later...

In any case, I don't expect -- nor ever intended --  this web app to be particularly useful in the cockpit in-flight, given the obvious technical limitations. However, the app does have various features designed to be very useful for flight planning when on the ground. For example, automated METAR and TAF briefings "nearest" to your current location (or anywhere else, by clicking on the map). It also has full Google geosearch capabilities -- so you can find and navigate to your hotel once you've landed!

In the meantime, you can try the app for yourself. It is available here, with a Users' Guide here. Certain features require registration. If you already have a FlyLogical account, that will work across all apps including this one. If not, you can create one for free, here.

Hope you find it fun, and maybe even useful ! Feedback always welcome via the Comments section below.

Sunday, 16 March 2014

Bulldog Weight and Balance Android App

I've wrapped my recently-published Bulldog Weight & Balance web app into an Android mobile app. The functionality of the mobile app is identical to the web app, but with the added convenience of having an on-screen icon which you can simply tap to activate, rather than having  to remember which URL to browse to.
You can download the app for free from the Amazon AppStore by clicking here from your Kindle or Android device. Note: if you are using a general (non-Amazon) Android device rather than a Kindle, you will first need to download the Amazon Appstore App to your device from here (since the Bulldog Weight & Balance app is distributed via Amazon rather than Google).

Saturday, 15 March 2014

iNavCalc: a complete flight planning solution for SkyVector

Update 11 May 2014: my brand new Really Simple Moving Map web-app has full route import and export inter-operability with SkyVector (in addition to the iNavCalc / SkyVector interoperability described below)

A while back I posted about SkyVector and talked about some very basic inter-operability with iNavCalc via the command-string interface common to both.

I hadn't taken another look at SkyVector in almost two years. But when I did, I was pleased to see that they have now provided Plain Text Link URL functionality. I've now adapted this to enable complete two-way intercation between SkyVector and iNavCalc. This enables you to combine the full power of iNavCalc for performing route calculations, planning, and sharing, with the full power of SkyVector for viewing & editing the route on (global) aviation charts.

Here are some simple step-by-step instructions for converting routes between iNavCalc and SkyVector


Enjoy :)c

Saturday, 1 March 2014

Bulldog Triplog Template

When I bought my Bulldog almost ten years ago, the previous owner very kindly provided me with a Microsoft Excel file containing a Trip Log template which I've been using ever since. A few years ago, I modified the template to include the new information required for Fatigue Monitoring (e.g., undercarriage leg serial numbers etc). I've been printing-off the template (20 blanks at a time) and filling them in after each flight. These have then been used as the basis for my submission to DHSL for annual fatigue monitoring.

I recently migrated the Excel document to a GoogleDocs Spreadsheet (screenshot below). I'm pleased to make this template available to any Bulldog operators who may find it useful. You can find it here.

Simply print-off some copies as you need them and fill them in manually, or make a digital copy to your own GoogleDrive (if you have a Google account), and customise to your own needs (e.g., type-in your particulars such as aircraft registration, undercarriage leg serial numbers, etc), then print-off copies as you need them.

For convenience, the template incorporates hyperlinks to my Bulldog Weight & Balance Calculator, my Bulldog Fatigue Index Calculator, and my Bulldog Checklist, all freely-available to anyone who finds them useful.




Friday, 28 February 2014

Long Live the File-System !

If you have spent much time building mobile apps -- or even using them -- you will know how painful it is to work around the lack of consistency regarding the treatment of file-systems across the various platforms. iOS is the worst. Last time I looked in any detail, the iOS file-system was heavily locked-down such that one is basically confined to the very limited sub-file-system associated with a given app: making it almost impossible to flexibly share files across apps, one of the best things about the file-system in the first place !

Android and Windows Phone 8 are better, but neither is as simple and effective as the good old desktop (or laptop). Perhaps that's one of the reasons why almost half of (the many thousands of) iNavCalc users, are still routinely using the "old-fashioned" desktop (laptop) web-browser version of the app (as opposed to the mobile versions). With the desktop (or laptop) browser, it is trivially simple, for example, to import and export GPX route files (via the Import/export button on the web-form), which happens to be one of the most commonly used features of the software.

I must admit I was a little surprised by all this. I had sort of assumed that the mobile versions of iNavCalc would rapidly outweigh the desktop version in terms of usage volume. But a year or so after releasing the mobile versions, the desktop still commands 50% (or so) of the daily action.

So, given these steady usage volumes on the desktop, I thought it would be good to spend just a little bit of time on improving the desktop version of iNavCalc. As such, and making good use of the file-system, I've enhanced the route file import/export functionality. Specifically, you can now do the following:

  • Import a GPX route file (this functionality was already present)
  • Import a Garmin FPL route file
  • Import a SkyDemon ".flightplan" route file
  • Export route to a GPX file (this functionality was already present)
  • Export route to a Garmin FPL file

These functions are all available via the Import/Export popup, as illustrated in the screenshot below.


Of course with the mobile versions of iNavCalc,  there is a workaround: namely exchanging files via email and via the Cloud storage functionality....but sometimes you can't beat the good old file-system in terms of simplicity and convenience. 

I  note in passing that the latest version of ChromeOS has a rather usable file-system. I was able to import/export route files via iNavCalc on the ChromeOS/Browser, with the same ease as I'm used to doing on Windows :)

Enjoy !








Sunday, 23 February 2014

Revenge of the Drones

Alas, my beloved quadcopter - complete with GoPro Hero 2 - featured in my recent post, has been lost at sea. It was unable to fight against the strong winds that carried it out to sea from the launch site in the Ramsey playing fields (Isle of Man).  Despite my best efforts to steer it to safety, the Irish Sea has claimed it.

An expensive lesson in the perils of flying beyond the weather limits of the aircraft...