OzRunways and iOS 11

iOS 11 has landed and people are probably wondering; can I update to iOS 11 and still use OzRunways?


The answer is yes you can!


Our team currently has OzRunways version 5.8.6 running on iOS 9.3.5, iOS 10.3.3, and iOS 11 without any issues. iOS 11 brings some very useful changes, especially for those running the new iPad Pro models – if you are in the market for a new iPad and can afford a 10.5″ iPad pro – our advice is to get one. It is a fantastic experience and easily a step above the current available iPad models.


iOS 11 multi-tasking has changed and is one of the areas which will really change the way we all use OzRunways and our iPads in general. We are looking at ways to leverage  this technology in to the future, but if you have iOS 11 check out the latest in multi-tasking Apple has to offer: https://support.apple.com/en-au/HT207582


A new version of OzRunways which takes advantage of the new features of iOS 11 is under development and will be available soon, but in the mean time prepare for the imminent arrival of version 6 of Oz RWY!

Replacing paper – Sources of aeronautical information and primary means of navigation: what are the rules?

The OzRunways team gets asked frequently about the rules regarding EFB usage; is it legal? Do I need a paper backup? We get asked these questions a lot and it leads us to believe that there is some degree of confusion amongst pilots and local authorities, with some people relying on out-dated or inaccurate information. So in this post, we are not only going to explain the rules around EFB usage, but we are going to provide you with the exact references for where to confirm them for yourself. Now to be upfront, this subject has the potential to be like eating weetbix with no milk, but we will do our best to keep it interesting!


The line-up at old station, 2016 – as always plenty of OzRunways subscribers on hand. Big shout out to the Buccaneers!

So why this post? Well, aside from the questions we get on this topic, we need to get this information out there because we have read, seen and heard various people (including a few wayward individuals from within the regulator) spreading misleading information about the legality of EFB usage. We also come across people every now and again who try to dissuade other pilots from using EFBs for various ill-founded or misunderstood reasons – it is usually not their fault as it can be tough to pin down the rules on new technology like EFB’s and in the absence of definitive guidance people tend to want to keep things the way they have always been done. Lets briefly put to bed one of the major reasons some are on the wrong side of history with respect to EFB’s, that is their potential limitations.

Like pretty much everything in aviation, EFB’s have limitations which if poorly understood and left untreated, can cause safety issues. But paper is not vastly different in this regard, it is just that people are used to paper’s limitations thus give them little thought day to day. For those who, like the OzRunways team did, grew up flying with ‘paper’ products, ask yourself; Ever had a paper map fly out a vent or open window, or blown in to the back seat out of reach? Ever had an air-conditioning vent spew ice and water on to your map, rendering it a soggy, unreadable mess? Ever gone to fold a map only to have it split as a result of being folded one too many times? Ever inadvertently flown with an out of date map, ERSA or approach plate? Ever opened your flight bag only to realise the one map or chart you need isn’t in there at a crucial time? I have had every single one of these things happen to me at least once in my career and many of you would have had the same. This small list of problems is exclusive to paper products and pilots had for years accepted these limitations and worked around them, probably without even realising; keeping maps deliberately away from vents, pointing A/C outlets in safe directions, taking care when folding maps, having a disciplined pre-flight NAV bag check are all steps pilots would take without giving it too much thought – it is the way we have always done it.


The pilots of these beautiful antiques certainly appreciate not having paper maps. Echuca 2016.

The good news is that managing the limitations of EFB’s is no harder, but it does require a different way of thinking. Overheating, battery limitations, lack of impact resistance, data updates, these things are all limitations exclusive to EFB’s which can be just as easily overcome through good practice and developing sound procedures, just like pilots have done with paper since the the dawn of aviation. The modern pilot can easily set themselves up for success through having having a heat resistant tablet cover, carrying spare batteries or have charging in the aircraft, smart ‘screen’ toggling, impact resistant covers, deliberate EFB pre-flighting – none of these mitigating actions is significantly more burdensome than what the pilots of yesteryear had to deal with, they are just different.


Maps can deteriorate quickly making them hard to read, especially in low light conditions.

So with that out of the way, what exactly are the rules for using an EFB? Let us explain it to you using the type of questions we typically get on this subject.

I am flying privately under the IFR/VFR. Can I use an EFB as the sole source of my maps and charts? Yes! For private operations, an approved EFB may be relied upon as the sole source of aeronautical information to a pilot in flight. (Ref CAR 233, CASR part 175, Electronic Transactions Act 199)


What is an approved EFB? An ‘approved EFB’ is technically a type of ‘approved service’ which can be used by Data Service Provider (DSP) to transmit aeronautical information. Importantly, a DSP must have been approved by CASA and issued a CASR Part 175.295 certificate, such as OzRunways was in March of 2016. An Aeronautical Information Service (AIS) could also technically produce an EFB. There is only one AIS in Australia however, Airservices Australia, and they don’t produce an EFB. The list of DSP’s can be found here. (Ref CASR Part 175)

Do I need a backup if I use an EFB? Legally, there is no requirement mandating the carriage of a backup for private operations. However, it is so easy to have one and good airmanship suggests it is a great idea, so why wouldn’t you? OzRunways recommends that for VFR flights outside of your local area that you carry an appropriate backup (see later paragraphs for more information). If you are privately flying IFR in IMC, OzRunways recommends carrying a second tablet, as shooting an approach off a chart on a phone whilst not impossible, is difficult.

If I carry a backup, does it need to be paper or can I use another tablet/phone? What is appropriate? There is no requirement to use paper charts as a backup to an EFB. Another EFB (either on a tablet or phone) is more than appropriate as a backup. This is reason your subscription with us automatically gives you access to the app on one tablet and one phone, so you have a backup (which you can mix and match between iOS and Android as desired). It is also the reason why we designed the OzRunways Premium with the personal backup tablet licence – so you can have two tablets without needing another subscription. If you want to fly VFR with a backup tablet, the personal back is available as a stand alone add on as well – it duplicates your active subs to a second device. Remember though, if you use another device running OzRunways/RWY as a backup, make sure it is charged and up-to-date before you go flying, just as you do with your primary EFB.


Luckily iPad failures are very rare, but why not carry a backup? The iPhone is a great backup especially for VFR flying, but flying an approach from one in IMC conditions can be challenging depending on your cockpit setup – OzRunways recommends a second iPad for IFR flying where possible – the OzRunways Premium subscription is great value with all the Australian data plus a personal backup license which enables your subscription on two tablets and one phone.

Isn’t a phone too small to use as an EFB? Is there a lower size limit for an EFB? There is no legal minimum size but CASA state that greater than 200mm diagonal for screen size is recommended. The iPad mini meets this minimum suggested screen size. A phone is typically smaller than 200mm diagonally, but for private operations it can be used as a backup; it will do the job in the unlikely event you needed it – just beware a phone is much harder to use, especially in turbulence/IMC. OzRunways doesn’t recommend using a phone as a primary EFB device.


No matter the mission, OzRunways is as a safe bet – thats why it is trusted by our defence force (and the RNZAF). OzRunways is the EFB used by every Air Mobility Group platform, such as the mighty C-130, and the RAN Fleet Air Arm.

Can I get in trouble at a Ramp Check with CASA if I rely solely on OzRunways? No. It is not only legal, it is safe to rely on OzRunways as your sole source of aeronautical information. If you get ramp checked you must be able to demonstrate that your OzRunways installation complies with the requirements of CAR 233, which includes having the required maps and charts downloaded to the device (On demand downloads do not satisfy this requirement), plus sufficient charge on your device to conduct your intended flight. The introduction of the Electronic Transactions Act 1999 means that electronic documents are every bit as valid and legal as paper documents – hence why information on a tablet, from an approved source is legal. AOC holders must comply with their AOC.

Can I keep my flight log in OzRunways? Do I need to keep a paper flight log? You can keep your flight log in OzRunways. There is no need to keep a paper flight log, unless you want to.To quote CASA on the subject (From CAAP 233):

‘The Acts Interpretation Act 1901; and the Electronic Transactions Act 1999 are the enabling legislation allowing the use of digital media to display the documentation required by the Civil Aviation Act 1988 and any of its subordinate regulations’
It is quite clear – you can keep a log digitally and you can’t be sanctioned at a ramp check for using your iPad to log your times and fuels. CASA staff familiar with the law will be able to confirm this for you.

Reg’s are a pain, what is this CAR 233, what does it say and how do I find it? You can find this CAR here or in the OzRunways App (OzRunways>Documents>CAR 1988 Volume 3>page 130). This CAR states a pilot must ensure that before commencing a flight that any aeronautical data and information required is carried in the aircraft and readily accessible to the flight crew. (Ref CAR 233)

What aeronautical information and data is required for a flight? The aeronautical data and information you require is that which is applicable to the route to be flown and to any alternative route that may be flown, and this data must be published by a Data Service Provider (CASR Part 175.295 certificate holder, such as OzRunways) or AirServices Australia. Think along the lines of maps, approach plates, ERSA, RDS etc. You can always discuss with a local flying instructor if you aren’t 100% sure. (Ref CAR 233, CASR Part 175)

I still feel more comfortable flying paper maps and charts though…maybe just as a backup Before we answer, let us start by saying the unique thing about the OzRunways team is that we are not just nerds, we are all qualified pilots –we have extensive experience in aviation among our team, including flying instructors with experience in RAAus, aerobatics, military, GA, Multi-engine heavy and jet experience. Add to that two of our people are human factors and aviation safety experts. OzRunways aren’t just the experts on EFB’s, we know flying safety as well. When it comes to someone still wanting to use paper, our answer is this: If you are not yet comfortable jumping straight from paper to EFB, then you should carry paper with you as well until you are happy to go all electronic. Or if you prefer a paper back-up, then use paper as a backup until such time as you feel it isn’t necessary. OzRunways is not ‘EFB at all costs’ – we are more passionate about airmanship and flying safely than EFB’s. But we know that even those who prefer paper will eventually see the benefits of having an EFB. If you think paper is needed in your cockpit to keep you safe while you transition to the OzRunways EFB, then there is no doubt in our minds, nor should there be in yours that you should use paper until the time comes you feel you can move away from it.


Still need paper? Why not print from OzRunways! Maps printed from OzRunways are safe and legal to use in flight. With iOS 10 you can also print to pdf from within the app.

Getting Started. We would certainly recommend that before you fly with OzRunways EFB for the first time you spend time with it on the ground getting used to it – check out some of video’s here, ask people in your local flying network for tips on how to set it up to suit your way of doing business. Also, it can help if you take some lessons with an instructor to get used to using an EFB (unfortunately CASA don’t yet have EFB’s in the pilot training syllabus). Long term the situational awareness benefits, ease of manipulation and immense data capacity of an EFB means it far outweighs using paper for aeronautical information.

If you do wish to use paper for any reason, remember: you can print from OzRunways! Save some tress and print what you need from the app – it is way more convenient and cheaper than sending off for AirServices charts. Printed material from OzRunways is still legal as it is from a DSP approved service.

I am an AOC holder, can I use OzRunways EFB? Yes, but CASA needs to approve this through your operations manual. See the CASA website for more information, including CAAP 233-1 (this CAAP is getting long in the tooth now and hasn’t been updated since CASR Part 175, but still has some useful information).


Would you rather carry an iPad or a 9kg NAV bag with most of the AIP – EFB’s can carry a substantial amount of data which is a benefit to private operators and AOC holders alike.

I am an AOC holder and I want to use EFBs but it seems like a lot of hassle Well the good news is OzRunways can help! We have the experience in house to help develop procedures and amend your AOC. Get in touch with us through OzRunways Support (help.ozrunways.com) to find out more.


You know whats more hassle than amending an Ops Manual? DAP amendments! Moving to a paperless flight deck is worth the investment. OzRunways intelligent design makes it so versatile, it suits everyone from the weekend trike flyer through to the IFR heavy flight deck.

Lastly, lets talk about ‘primary means of navigation’ and the OzRunways EFB. This phrase gets misinterpreted a lot, which is understandable given the phraseology can mislead pilots in to thinking that you can’t use OzRunways to gain navigation information. The question we often get goes something like:

But I heard we can’t use OzRunways as the primary means of navigation, how can it be legal? The restriction of use for primary means of navigation is referring to specific navigation elements of the EFB: in particular, any device derived GPS position data such as  your OzRunways aircraft position, present lat/long, HSI display etc. These features of the app can only be used as a supplement to your primary navigation source. They are there to enhance your situational awareness only – that is, treat the iPad position data as a ‘VFR GPS’.


OzRunways is used by the ADFs aviation training units, including ADF Basic Flying Training School in Tamworth, NSW.

As an example, you can’t fix yourself by looking at the OzRunways EFB, seeing the aeroplane symbol over a town and saying ‘the OzRunways aircraft symbol says I am here therefor I have fixed my position’ – that would be relying on the device GPS as a primary means of navigation which you cannot do. What you can do though is look at the EFB, see the aeroplane symbol over a town, assess the other features on the map around the town OzRunways says you are over, then look outside and do a Clock to Map to Ground visual pinpoint to fix yourself. Of course it is more than likely that your visual pinpoint will correlate with your iPad GPS position shown in the EFB. This is called using the OzRunways EFB as a supplemental source for navigational information – it is there to assist you in position fixing and provide enhanced ‘situational awareness’ which can supplement your primary means of navigation.

When using OzRunways, you must position fix using either a proper visual fix or approved NAVAID in accordance with the section of AIP relevant to your category of flight (such as a VOR/NDB if you can find one, or a CERTIFIED GPS fitted to your aircraft – remember certified equipment and certified pilot are needed here – see AIP for more information). Again though, don’t be confused – you can use the OzRunways EFB to derive the aeronautical information needed to assist you to fix yourself though (i.e. the maps are legal to use to discern features, frequencies etc).

One thing it is worth reminding pilots of – the restriction on using OzRunways as the means of primary navigation also means your OzRunways GPS position isn’t a valid way of avoiding airspace (restricted or controlled) – you MUST avoid airspace using an approved means of navigation (and by the appropriate margin!).


So to sum it all up – The Aeronautical information in OzRunways EFB is legal; it is good to go as a sole source for private operations (AOC holders must comply with the requirements of their OPS manual); OzRunways EFB GPS position information is only to be used to supplement your primary means of navigation.

Thanks for sticking with it if you got this far! Fly safe, see you at your next local air-show or fly-in.


The OzRunways team


Inside OzRunways

Using an interesting tool, you can explode out views into layers to see how they all composite together to achieve the final image. I think it looks cool:



Drawing individual images is expensive, so you can see what we’ve done here is load three bitmap pictures once and we rotate (animate) the outer pointer to change the track.

Below is the vertical toolbar that slides out. The little fuel ones are hidden underneath and animated out. You can see the transparency of the toolbar is set to about 95% so you can see just a tiny amount of map underneath (to look natural). The GPU must go and calculate all of the blending required for doing this as you pan the map (at 60 fps) leaving less than 16 milliseconds to do all the calculations in order to maintain smooth scrolling.

toolbarScreen Shot 2016-03-02 at 11.11.50 AM

Here’s the whole main map screen minus the backing map. You can see the GPU has to composite, crop and blend many layers of images with a different z (vertical) order to achieve the final image. You can override the z order of an object in code to force it to appear at the top of the screen.



Here is the final image with all cropping and blending done. Cool !

Full Screen

Creating RWY Go


Today I want to discuss some things that happen behind the scenes when creating a new app, and in this case, RWY Go.

When Apple announced the Watch, we did some brainstorming about what we would love to see on it, and came up with some screenshots:



Yes, very lame I know (particularly the old school watch!). We had no idea what the resolution or features the SDK would support, so this was all just guess work. It turned out the SDK was fairly restrictive so it actually led the design in a different direction, which I think turned out to be a good thing.

Goal and design philosophy

We wanted something useful to use on iPhone and Watch to give useful, time critical information normally scattered across ERSA and approach plates, with zero or minimal user interaction in a divert or emergency. Here’s what we came up with:

  1. Where to go – What is the most intuitive way to represent the distance & bearing in a glance.
  2. Arrival Plan – Runway orientation, elevation, windsock and runway numbers. The entire diagram should rotate for orientation. Layered based on priority.
  3. Frequencies – Important ones starting with CTAF/TWR, then ATIS and navaids. These are ordered based on usefulness.
  4. Met & Notams – Low priority, so accessible via a swipe.
  5. Searchable – One tap shows a list of airfields ordered by distance. A runway diagram makes selection easier.
  6. Contrast – The colour scheme needed to work in both broad daylight and in a darkened night cockpit.

Class Design

As soon as Apple released the watch and SDK to developers, we had a look through to see what it could do. We very quickly discovered that the entire binary was run on the iPhone, communicating wirelessly to the watch to update the interface. The interface needed to have a static design layout (created at compile time) and the iPhone sends some basic low-bandwidth numbers to update it. It could do some basic images and animations. We also needed to create a ‘container’ iPhone app, which we hadn’t planned on doing. As it turns out, I think the iPhone app for RWY Go ended up being the best bit.

So the basic concept is that the iPhone app launches and gets a location, then chooses the best airport nearby. It procedurally draws some images of the airport and saves it into a shared container both the watch binary (also running on the iPhone) can use. It also fetches the Met & Notams and saves those for display.

Here’s the first draft I used as the overall structure for the app (how all the bits and pieces connect together):


The implementation was a lot more complex as you work through issues & test the limits of what the SDK can do for you. This was my first project using Apple auto-layout and Swift which was awesome for this project. Here’s the auto-layout for the iPhone app in XCode:


Essentially, all of the elements on screen are built up with relationships to each other. It requires tons of testing and tweaking on all of the different devices in portrait & landscape, but once done, works perfectly in native resolution in any interface orientation.


The Watch interfaces were created in a similar fashion by dragging & dropping elements onto a screen. With some nested grouping of items, it’s possible to achieve a nice interface on both watch sizes. We didn’t actually have any devices to test on, so it was all done in the Simulator. Apple only allowed 1 day in Sydney playing with the watch prior to public release to check it worked.


The Watch doesn’t do animations the same way iPhone/iPad does (e.g. “Rotate this image by π/2”). You need to specify 360 individual images and have them flash up quickly. Yes – you need to create 360 images in Photoshop. Then another 360 every time you change the design!

compass_220-0@2x compass_220-1@2x compass_220-2@2x compass_220-3@2x compass_220-4@2x compass_220-5@2x compass_220-6@2x compass_220-7@2x compass_220-8@2x compass_220-9@2xcompass_220-10@2x compass_220-11@2x


The first lot of artwork we used was yellow, then a light blue theme, however we settled on a darker blue theme which worked better for iPhone at night in a dark cockpit. The centreline markings were also removed and as it looked too busy and cluttered. We wanted an interface that could, in a snapshot, be used to give you the orientation and direction of the runways without your eyes getting lost in the picture.

First version – Runways drawing!


Second version – circle concept
Runways don’t fit well yet


Here’s some other designs – some of these look really awesome and it was a difficult choice. At first the ones with high contrast circles look the best, however you’ll quickly realise that the large circle is redundant information and drowns out the actual data. The dark blue circle works better at night and allows the white arrow + text to stand out better.


And some different ideas for runway drawings and frequency design. It turned out these don’t really fit well on the watch and some other technical limitations made them impossible to do well. We went with green/brown lines for grass/dirt runways as it’s more intuitive.

This looks modern but which is the grass runway?

IMG_3487 IMG_3490


RWY Go Watch
Final Design.



Database creation

We had an extensive database of runway thresholds from Airservices Australia and other sources, however it didn’t cover a lot of the smaller airstrips or international airports. So we created our own data set.

Using Google Earth, we plotted the position of every single airfield we knew about, then went about mapping the thresholds and runway type (grass, dirt, bitumen) for each airport. The current count is 28,164 runways across 23,562 airfields around the world. Painstaking work! We managed to squeeze all of this data, plus navaid / frequency information into a 6.1 mb database which is updated every 28 days.

Drawing airfields

Probably the most nerd satisfying part of creating this app was procedurally drawing the airfields from a bunch of lat/lon pairs for runways. The easy bit is creating a class that converts lat/lon pairs to an x,y pixel coordinate based on the maximum and minimum latitude and longitude pairs found for that airport. Here’s a snippet with some corrections to squeeze the runways inside a circle:

        //Center any axis that would otherwise be at the top or on the left (so the image is centered)
        if new_xScale < xScale {
            let scaleDifference = 1.0 - (new_xScale / xScale) //(e.g. compressed 50% would be 0.5)
            xOffset += (scaleDifference / 2.0) * Double(clippedRect.size.width)
        } else if new_yScale < yScale {
            let scaleDifference = 1.0 - (new_yScale / yScale)
            yOffset += (scaleDifference / 2.0) * Double(clippedRect.size.height)
        xScale = new_xScale
        yScale = new_yScale
        //Correct so any diagonal runways outside of the circle are put back inside for rotations.
        // iPhone & iPad only (not Watch):
        if fitInsideCircle {
            let center = CGPoint(x: rect.width * 0.5, y: rect.height * 0.5)
            var longestThresholdFromCenter = 0.0
            for runway in apt.runways {
                let p1 = latLonToPoint(runway.threshold1.position)
                let p2 = latLonToPoint(runway.threshold2.position)
                let p1Dist = (p1.x - center.x)*(p1.x - center.x) + (p1.y - center.y)*(p1.y - center.y)
                let p2Dist = (p2.x - center.x)*(p2.x - center.x) + (p2.y - center.y)*(p2.y - center.y)
                longestThresholdFromCenter = max(longestThresholdFromCenter, sqrt(Double(p1Dist)))
                longestThresholdFromCenter = max(longestThresholdFromCenter, sqrt(Double(p2Dist)))
            let desiredRadius = sqrt(Double(center.x * center.x)) - Double(rect.width*0.16) //assume square image & reduce by a further 16%
            if longestThresholdFromCenter > desiredRadius {
                let overhang = longestThresholdFromCenter - desiredRadius
                let reduction = sqrt(overhang*overhang*0.5)*2.0
                xOffset += reduction * 0.5
                yOffset += reduction * 0.5
                xScale *= (1.0 - reduction/Double(rect.size.width))
                yScale *= (1.0 - reduction/Double(rect.size.height))

The runways are then drawn on as a simple drawing call (“draw a box from (a,b) to (c,d) width 4.0”). The entire thing is saved as a small image and cached. It also draws a diagram for the search results (with no labels, thinner lines) and the Watch, which can be slightly larger as the image doesn’t need to rotate.

The tricky part is positioning the labels as subviews to the runway diagram so they rotate the opposite direction to the runway diagram and don’t overlap. For example, in the diagram below, RWY 04 at EHAM (Amsterdam Int’l) is shifted to not overlap with the other numbers. It took a couple of hours of tweaking drop shadows, font size and colours of the labels to have them readable with a high contrast over the top of the runways. Bonus points for the reader if you can figure out how to dynamically place a windsock on a runway diagram (choose an x,y position), in a good looking spot, that doesn’t overlap with any of the runways or labels – the only data is N pairs of runway thresholds (a,b), (c,d) where N >= 1.

Runway1 Runway2List

The windsock appears after it has downloaded the TTF, TAF and METAR for the airport. It uses a regular expressions to search through and find text like 23025KT or 18030G42KT prioritised by METAR, SPECI, TTF then TAF. The result should be a windsock that is very close to the wind right now.

Hypoxia Alerts

Soon after releasing RWY Go, we looked at the altimeter on the iPhone6 and wondered how we could use it. Because it will be measuring cockpit static pressure which has loads of errors, it’s fairly useless as an altimeter. The best use you can use for cabin altitude is to use it for cabin altitude! For those that don’t fly above 10,000 ft on oxygen, hypoxia is a big deal. The time of useful conscious decreases rapidly from about 30 minutes at 18,000 ft to 3-5 minutes at 25,000 ft. And the clock starts ticking above 10,000 ft so if you have had a gradual ascent (perhaps loss of cabin pressure), your time at 25,000 may only be a minute or two. What RWY Go does is start a timer above 10,000ft that ticks down at a certain rate to simulate your O₂ saturation. The higher you go, the faster it ticks down. When it gets to a very conservative threshold (about 50% of the published times), it will show a message to check oxygen. It goes without saying this isn’t a certified system and shouldn’t be relied upon in place of proper equipment and procedures. It’s an extra help that may come in useful one day, or to provide education with how long it can take to become hypoxic. Hypoxia alerts can be disabled in iPhone Settings.

[embedyt] http://www.youtube.com/watch?v=UN3W4d-5RPo%5B/embedyt%5D


Well I hope that gives some insight into what goes on behind the scenes. This has probably been the most enjoyable small project I’ve ever worked on. Swift is a really awesome language to program in, plus working with our artist and brainstorming design paradigms is great fun. Since writing the app, Apple have released Watch OS2 which allows native binaries to run on the watch. I’ve updated the iPhone/iPad code already, but now need to do a massive rewrite of the Watch code to support this change. It should result in the watch app loading and displaying content much quicker than wireless transfers do at the moment.

RWY Go 3_small


CHC Helicopters Goes Paperless


CHC Australia is a subsidiary of CHC Group Ltd (“CHC”) the world’s largest commercial operator of medium and heavy helicopters. They provide transportation services to the offshore oil and gas industry. The company also provides transportation for emergency medical and search and rescue.

CHC’s Heli-One is the world’s largest non-original equipment helicopter support company, providing repair and overhaul services, leasing, logistics support, parts sales and distribution, in more than 20 countries.

In Australia CHC provides oil and gas transfer services off the north west of Western Australia as well as a search and rescue service based in Broome. It also provides rotary aero medical services in three states and conducts search and rescue for the Royal Australian Air Force (RAAF) to recover pilots if they eject from their aircraft during training.

Says Coakley “Using OzRunways has given CHC a triple treat:

  1. It’s a brilliant pilot’s tool in its own right for both planning before hand and situational awareness in flight;
  2. It all but eliminates paper in the cockpit; and
  3. It has delivered economic and operational savings doing away with all those expensive and constantly requiring updating charts, manuals, plates, forms etc.”

CHC Australia are a long-term customer and enthusiastic fan of OzRunways – both the electronic flight bag (EFB) and the company. Says Tom Coakley, pilot and spokesman for the company: “We have 88 iPads, running the OzRunways EFB, in 34 aircraft, across 15 bases, in Australia and East Timor. The EFBs are supported by detailed, international standard manuals, training programs – including online courses, and support systems”.

The CHC pilots found the iPad 2 a little too bulky for their cockpits but have recently changed to the iPad Mini which seems perfect.

IMG_4648_1Although CHC have tried other EFBs Coakley says there is overwhelming support by the pilots for OzRunways. It’s not just the tool itself says Coakley but the outstanding support from the team at OzRunways.

But the story gets better with CHC working with OzRunways to further enhance the product – both generically for everyone, and specifically for the unique needs of CHC.

The subject of customer service and 24/7 availability was emphasised by Coakley when he said “We could not speak more highly of the support team at OzRunways, especially Dean. Many times he has rung us back at odd hours from home because he knows how important it is for us to get quick service, and we can hear the kids in the background. What great service!”

Asked to give an example of OzRunways in situ Coakley, who also flies for CHC, told the personal story of a recent rescue from Bankstown in the remote Grose Valley, 45nm west of Sydney. Says Coakley “We used OzRunways to improve aircrew situational awareness of the nearby restricted airspace. Further, when the weather closed in quickly, threatening our ability to recover an injured climber, we were also able to use the radar overlay to gain a better understanding of the situation and how quickly it was deteriorating. OzRunways made all the difference to the crew’s situational awareness and the ability to make a difficult rescue possible.”


Creating OzRunways traffic

And why you should use it!

In this post I’ll discuss some technical aspects of how we created the OzRunways traffic system. This will be at a nerd level but others may find it interesting.

OzRunways Traffic

Lets start with the requirements for a traffic system. It must be:

  • Low latency,
  • Reliable,
  • Contain a lot of important information, and
  • Able to be used on flakey mobile data networks with high losses.

We settled on UDP as the protocol of choice. UDP has some good characteristics that make it useful for traffic. For a start, it works extremely well over poor network connections. Imagine UDP as “send send send” vs TCP which involves handshakes and a flow of ‘ack’ packets back and forth to establish a reliable connection. Traffic is time sensitive so if an UDP data packet is lost, we don’t care as the next one to arrive in a few seconds completely replaces the data from the last one.

To use UDP with maximum reliability we had to look at how to send a single packet with all of the information we need without the 3G network fragmenting it into multiple packets. A quick google showed that using less than around 500 bytes for each packet (plus the IP header) should guarantee it being sent out as a single packet across 3G networks.

The basic infrastructure involves the OzRunways iOS client sending out its position, callsign, flight plan, unique identifier and a few other details (climb rate, track etc). Our server is a simple echo server that saves this to a database and sends a single packet back with the details of a bunch of nearby aircraft for displaying on the screen.

The OzRunways client firstly needs to check whether we are flying to send packets. We settled on a simple algorithm that uses a combination of timers, height above ground (using the NASA SRTM terrain database) and forward speed to test whether flying. The timers are used for touch & go’s to allow a minute of slow speed and low height so the system keeps sending packets until taxiing clear of the runway. To protect user privacy, once detected not flying, we send an incorrect user position and disable an airborne bit in the packet so the server still sends back nearby aircraft to display, but does not save the client position in the database to display for other users.

For the actual packet implementation, we needed to squeeze as much data as possible into ~ 500 bytes. The biggest saving is coming up with an implementation for a latitude/longitude pair that can be squeezed into a small number of bits. For example a packet sent back with 10 nearby aircraft with flight plans of 5 points each would contain 50 lat/lon pairs. If we have 6 bytes for each lat/lon, that would chew up 300 bytes. Using a standard 4 byte or 8 byte float/double was therefore not ideal.

For our lat/lon pair we looked at the resolution required by dividing earth up into X segments both vertically and horizontally. Since latitudes are +90 to -90, there is 180 degrees of space available. For longitudes, it’s -180 to +180 = 360 degrees at the equator. Longitudes further north or south would be squished so result in better resolution so we’ll use the Equator for worst case.  Here’s the calculations for latitudes:

1 bit of information = 90 degrees resolution available (180 / 2^1)
2 bits = 45 degrees (180 / 2^2)
8 bits (1 byte) = 0.7 degrees (42nm resolution)
16 bits (2 bytes) = 0.0027 degrees = 0.16nm (300m – we’re getting close).
24 bits (3 bytes) = 1.2m resolution.

Excellent – so instead of a 4 byte float, if we represent +90 to -90 of Earth’s latitude as +0 to +180 sliced up into 16,777,216 pieces, we can just send a 3 byte integer. The decoder can just multiply the number by 0.00001072883606 to get the latitude with about 1-2m resolution, which is perfect for our traffic system.

+ (int)readUnsignedMedium: (const void *)bytes {
    int n=0;
    memcpy(&n, bytes, 3);
    n = n << 8;
    return NTOHL(n);

We did the same calculations for all of the data. We could squeeze a lot of data into 1 byte (for example vertical speed with a resolution of 100 ft/sec) resulting in an overall packet size of ~ 80 bytes (includes 20 byte IP header) when sending our information out. This is why the OzRunways traffic system is so reliable — an 80 byte UDP packet is about the most reliable thing you can send out of a little iPad antenna at 24,000 ft. We tried gz compression but did not get any gains for either 80 or 500 byte packets.




For the echo server, we jam as many aircraft as possible into the return packet until we hit 500 bytes. We include all of their information, timestamp (for dead-reckoning their symbol on the map) and flight plans. We average around 18 aircraft per return packet which is why you only see nearby aircraft. You can see all traffic at tx.ozrunways.com

In the end, we have written an entire packet specification mapping out individual bit values including some reserved bits for additional features (e.g. an ’emergency’ bit) should we choose to implement them. We think it’s more flexible than the ADS-B specification as we can send & receive flight plans of other users.

There’s obviously a lot more that goes into the traffic system such as database design (storing tens of millions of data packets for fast access), interfaces for SAR agencies and human-interface design of the traffic icons on screen however I can’t go on forever! Let’s finish with a screenshot of somebody landing in remote QLD:


As you can see, the 3G coverage is very good with UDP. If this person were to crash, we could give SAR agencies an exact position. You can also see the timer working to disable the traffic feed after the pilot has landed and taxi’d off the runway.

Fly safe.