Saturday, 11 April 2015
Saturday, 7 March 2015
Thursday, 19 February 2015
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
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
Sunday, 17 August 2014
Meaningful criteria for the approximate probability distributions
- 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
Probability Density Function (pdf) for YES
Probability Density Function (pdf) for NO
What are these good for ?
Thursday, 24 July 2014
Saturday, 19 July 2014
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
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
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
Saturday, 15 March 2014
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
Saturday, 1 March 2014
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
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
Sunday, 23 February 2014
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...
Saturday, 22 February 2014
I did some instrument flying refresher training the other day with an instructor plus a bunch of (heavy) documentation on-board. Got me thinking about weight & balance. Normally I fly solo so am well within the loading limits of my Scottish Aviation Bulldog, and hence I don't need to check routinely.
Anyway, when I was calculating the loading and checking against the charts and graphs in the Pilots Operating Manual, it struck me that this would be a very good example of a calculation well-suited to a web-app.
So I put one together (see screenshot below) and have published it for general use. You can find it here.
It is free to use. If you register with FlyLogical (also free), you can save (and retrieve) your settings across sessions.
Hope you find it useful.
Saturday, 25 January 2014
- Walkera QR X350 quadcopter UAV ("drone") with GPS and compass
- GoPro Hero 2
Wednesday, 1 January 2014
Here is the current list of sources where iNavCalc gets its data. You will note that some sources are official, but since FlyLogical is not an official (re-)distributer of such data, all FlyLogical web-pages and apps carry a warning and disclaimer about not relying on the data without reverting to the original official sources.
- METARs and TAFs: US National Center for Atmospheric Research (NCAR) under sponsorship of the Federal Aviation Administration (FAA). This is an official data source. URL: http://weather.aero
- NOTAMs: US FAA Aeronautical Information Data Access Portal (AIDAP). This is an official data source.
- Atmospheric temperatures and pressures used in PLOG calculations: same source as METARs for surface data, then application of standard atmosphere model to extrapolate from surface measurements to flight altitudes. For each waypoint, data from the nearest METAR reporting station is used, so results must be considered as approximate.
- Winds-aloft used in PLOG calculations: same source as METARs for surface data, then application of boundary layer model to extrapolate from surface measurements to flight altitudes (see http://es.ucsc.edu/~jnoble/wind/extrap/index.html ). For each waypoint, data from the nearest METAR reporting station is used, so results must be considered as approximate. Note: previous versions of iNavCalc utilised the NWX web-service ( http://www.navlost.eu/aero/nwx_help ) for deriving winds-aloft forecasts from the NOAA GFS models ( http://www.ncdc.noaa.gov/data-access/model-data/model-datasets/global-forcast-system-gfs ). However the NWX service has been intermittent of late, and no longer seems to be actively supported. As such, the alternate method of extrapolating from METAR surface winds has been adopted. This approach must be understood to be approximate, not least since the boundary layer model is itself approximate. Moreover, an average value of 0.1 is assumed for the surface friction parameter in the model, thereby not taking account of local variations.
- Geomagnetic declination: a local implementation of the World Magnetic Model (WMM), developed jointly by the National Geophysical Data Center (NGDC, Boulder CO, USA) and the British Geological Survey (BGS, Edinburgh, Scotland) . URL: http://www.ngdc.noaa.gov/geomag/WMM/DoDWMM.shtml
- Solar angle calculations: local model based on Earth-Sun orbital model
- Airport database: originally derived from the OurAirports.com community-maintained database, complemented thereafter by FlyLogical and by iNavCalc users
- NAVAIDs database: originally derived from the OurAirports.com community-maintained database, complemented thereafter by FlyLogical and by iNavCalc users
- NAVCOM frequencies: originally derived from the OurAirports.com community-maintained database, complemented thereafter by FlyLogical and by iNavCalc users, and since 19 February 2015, automatically updated via openAIP.net on a weekly basis
Saturday, 16 November 2013
The result is simple set of hashtags (#met, #notams, #route) which you can use to generate MET, NOTAMS, and routes directly from your tweets. All you need is a Twitter account. To get started, see the simple instructions here.
Saturday, 9 November 2013
Enhancements in V3
- Load and Save Routes in the Cloud
- Auto-open app when clicking on .GPX or .FPL files (Android only)
- Share routes
- via Twitter (#ROUTEVIEW)
- via Email
- with other iNavCalc users (public or private)
- "Like" feature for voting as a "Cool Route"
- Various UI improvements and bug fixes
New features in V3
- METARs & TAFs page with global ICAO lookup
- NOTAMs page with global ICAO lookup
- "Cool Routes" page for displaying most-"Liked" routes
Sunday, 29 September 2013
Here's the route (generated using iNavCalc RouteView) we flew in to EGBK from EGSF where the aircraft were positioned after Leuchars.