AFPEx and smartphones [Archive]

IO540

19th Feb 2010, 09:35

iPhone app would be ideal - especially for those operating out of farm stripsDo you get 3G reception at your strip(s)?

You may well get a GSM (voice calls, SMS) signal, which generally means you will also get a GPRS (slow internet, c. 20k bits/sec) service.

But 3G (faster internet, c. 500k bits/sec) is poorly served away from the metropolitan areas and major roads - everywhere in Europe. AFPEx works OK on GPRS but every so often they force a download of the whole Java application (presumably because they have changed it) and then you are stuffed if you have only GPRS; the download is about half an hour and often breaks...

Caching the application may work, in the same way that it may work on a windoze laptop. I have still not been able to determine the best procedure for this; with my laptop I make sure I refresh the Java application shortly before a trip, and use Hibernation thereafter. And if I am away, on GPRS at £7.50/MB :) and I get hit with the download, I kill it and use EuroFPL or Homebriefing instead :) Sadly, HB have b*ggered their website with tons of graphics recently, which is a shame as HB is the only non-AFPEx method for electronic VFR FP filing. EuroFPL does only IFR (and only if you pre-validate the route; the 'reroute accepted' thingy cannot be used) but that's OK for me since I fly almost only IFR when going abroad, and always a pre-validated route. But it's not a solution for some 99% of UK PPLs, many of whom (IMHO) are too stingy to pay 4 euros to HB :) I still run a HB account but with the combination of AFPEx and EuroFPL have not used it since last June.

The funniest/saddest thing is that when you file a VFR FP via HB, they don't file it to the AFTN; they merely forward it to the departure ARO where - in the UK - some poor sod has to address it and type it in manually with...... AFPEx :ugh:

IMHO, if AFPEx want to cater for mobile users properly (not just some phone app but mobile internet generally) they need to run a documented update schedule so that e.g. the application is guaranteed to not get updated except on the 5th of each month, and the previous (assume: Hibernated/cached) version is guaranteed to work until the 10th of the same month. This is really basic stuff....

Yesterday I met a bloke who has been in the airport services business for decades - quite a big company - and they tried to sell electronic flight plan filing solutions to UK ATC for many years, and always got rebuffed on obviously spurious grounds. This business has been wrapped up in job preservation politics from day 1.

kui2324

19th Feb 2010, 18:25

XA NATS in Glasgow and Edinburgh are moving over to the electronic stuff in the next month or so.

Full house then with Aberdeen! Have they arranged with you what/how/when etc cos despite asking think our lot are not coping well and have yet to meet with us. :*

Date now slipped to May/June.

We in the frozen north would be interested to hear what's happening further south.

Scott Diamond

19th Feb 2010, 21:03

Mid-March for Edinburgh then later into June/July for Glasgow is what I've heard

derekf

19th Feb 2010, 22:40

IO540 - you're missing the point of an iphone app. Why would you need 3G at the strip? f the app had everything built in and just validated / sent the FPL you'd need less bandwidth than any other FPL app you can think of (HB,EuroFPL etc)

IO540

20th Feb 2010, 06:49

That's impossible.

It's too obvious.

It can't be done.

Why? The computer says NO.

But seriously: the team at AFPEx are technically very good (I've met some of them) but ISTM that the major software is bought-in, and IMHO there is nil chance of anybody there being able to make the required financial case for spending (probably) 6 digits on software development.

You could achieve what you want (as you of course know, given your job) by setting up a web (or whatever) gateway on some IP, and having a bit of software running on that which interacts with a real AFPEx application, sufficiently to file a flight plan and maybe (for strip flyers) to also file the DEP message, but then somebody will want to support the cancel message, then somebody will want to support the free text, and then.........

:)

Anyway, I know somebody who could knock up a simple proxy like that for a few k. It would prob99 be in breach of the AFPEx Ts & Cs though.

You could even file it via an SMS message. The protocol between the phone and the server is up to you, of course.

My guess is that EuroFPL would be the people to talk to about this kind of thing.

That is, after somebody has solved the issue of VFR addressing; which could be awfully fiddly if done manually on a phone. This could be done by the phone app, by walking the filed route and picking off the FIRs, then applying the special cases. Not completely trivial but possible.

Nobody is going to do this for free though.

S-Works

20th Feb 2010, 08:56

I am not sure it would be that complex to develop an iPhone app. The beauty of the iPhone is it is a proper development environment rather than trying to achieve some tie up through html. A simple gateway into the AFPEx system through an app that can provide the required level of security might be an option.

We are developing an app for the ipad/iphone that will display IAP, it might be worth talking to the NATS guys and seeing if there is anything that can be done. I will report back!

kui2324

20th Feb 2010, 10:42

YSW no you don't know anything ;)

But I think the LOA's with certain strips will need to be negotiated! Think the powers that be might have forgotten that ...

IO540

20th Feb 2010, 14:10

IMHO nobody is going to devote significant resources to writing an Iphone app for flight plan filing.

Very few pilots have Iphones and only the most fashion conscious or expense-funded people carry one - given the ludicrous cost of the contract.

Most heavy business GSM users have Blackberry type devices.

If any effort is to go into R&D it should be a simple HTTP submit form for the ICAO flight plan form. Then everybody with mobile internet can use it.

And EuroFPL delivers that already - for pre-validated IFR flight plans.

The real trick is doing it for VFR flight plans - "somebody" has to solve the addressing issue because one cannot really imagine a "phone" user typing in a string of EGxxxxxx addresses (and where is he going to find them anyway, if all he has on him is the phone?).

So - to rephrase... the challenge is not really in developing a web form for efficient FP filing. It's already been done. The bigger challenge is to solve the VFR addressing issue, and solve it for free because 90%+ of UK PPLs will not want to pay for a service.

Homebriefing could no doubt knock up a simple 320x240 web form for FP filing, but a) few UK PPLs would pay 4 euros per FP and b) the resulting VFR FP would anyway be merely forwarded to the very same airfield where they told you to use AFPEx in the first place ;)

The Grim EPR

20th Feb 2010, 17:48

An option that I have explored is the Logmein 'app' for the Iphone. With this, I log on to the laptop at home, which has a stable, speedy internet connection. That way if the Afpex system needs a large update, it can be done at speed. Also if the connection to the phone is lost, everything remains on the laptop which you are controlling remotely, until you reconnect.

This is not ideal, but it is a workaround.

IO540

20th Feb 2010, 19:07

Spot on - that is the "remote desktop" way of doing it.

One can use

- pc/anywhere
- windoze remote desktop / terminal services
- citrix
- loads of others e.g. this (http://www.remote-desktop-control.com/)

I have only ever tried the first one (PCA) and it doesn't really work with the Java app. Windows' own remote desktop would be the next one to try - has anybody done it?

Mind you, any kind of remote desktop is IME not really usable over GPRS. It works but it is really slow. You need 3G.

smithgd

20th Feb 2010, 19:13

So what about the Blackberry, has anyone tried AFPEx on that?

I assume accessing the other usual pre flight stuff is ok on any smartphone since they are all normal web pages?

cheers
smithgd

IO540

20th Feb 2010, 19:50

AFPEx is not a website - it is a client-side Java application of about 3MB in size. AFAIK no current "phone" device runs it. The Ipad might perhaps???

In general, www-capable phones can access most normal websites but there are occassional issues because these browsers are not quite Internet Explorer compatible.

I have a pocket/pc PDA (Fuji LOOX N560) on on that I have Pocket Explorer and Opera; one works on some sites and the other works on some others :) That said, pocket/pc is crap anyway and I am sure the more modern stuff like the Iphone are a lot more compatible.

My Nokia E51 runs most small aviation weather sites OK, but the panning is painful at times, so I use it for tafs/metars only.

IMHO, preflight stuff needs a laptop. Can be a very small one but anything smaller than a laptop is just painful. Unless one is happy to skip some steps, like getting notams ;)

englishal

20th Feb 2010, 22:24

Couldn't this easily be solved by having the Java app as a one time download. The actual volume of data sent from client to server is pretty low AFAIK. Many "smartphones" run Java these days.....

IO540

21st Feb 2010, 07:10

After being a every-time download for about a year, the AFPEx Java app is now a one-time download.

Except they update it every so often, and then you get the whole 3.5MB coming down your PAYG connection when you are abroad :)

tmmorris

21st Feb 2010, 15:56

I can't get 3G (or any) O2 reception at the strip* I fly from...

Tim

*AKA a major RAF rotary base...

FlyUK73

21st Feb 2010, 19:56

There is an update to the software on the 4th of march at 2200 UTC, so if you click login on the website after that a download will be forced.

if you visit:

https://ts1.flightplanningonline.co.uk/

https://ts2.flightplanningonline.co.uk/

https://ts3.flightplanningonline.co.uk/

and download the new version after the update (about 2300) from all three links you won't be asked to download again until the next update.

If you download from only one of the above links, the next time you try from a different link the terminal server (ts1, ts2 or ts3) will see your software as out of date and force a download.

Hope this helps.

IO540

21st Feb 2010, 20:31

FlyUK73

This is very helpful, but raises some points:

1) a lot of people download from http://www.flightplanningonline.co.uk/ which then changes the URL to one of the others - which one, seems to vary

2) why download from all three?

3) will you publish an update schedule?

4) if one is running the cached version, by executing ats.xjnlp.jnlp loader rather than going to the website, the ts1/ts2/ts3 server selection appears to be determined by the loader file; mine contains ts3 in one place and all three lower down :)

ILOC

22nd Feb 2010, 13:19

IO540

AFPEx is not a website - it is a client-side Java application of about 3MB in size. AFAIK no current "phone" device runs it.
I don't have a Windows Mobile phone at the moment but apparently Java has been available for them for some time now.

The Ipad might perhaps???

Unfortunately not - Apple have made it very clear that they will never allow interpreted code such as Java (or Flash) to ever run on the iPhone or iPad. It's unfortunately rather typical Apple arrogance in assuming that everyone will come around to their world view and stop using them.

In general, www-capable phones can access most normal websites but there are occassional issues because these browsers are not quite Internet Explorer compatible. This isn't really to do with Internet Explorer compatibility, more to do with a combination of the phones built in browser not doing a good job of resizing/shifting things around to fit on a small screen, and the website not being designed to be viewed that way. Firefox and Chrome have grown so massively in popularity that only the worst designed websites aim to just be IE compatible.

That said, pocket/pc is crap anyway and I am sure the more modern stuff like the Iphone are a lot more compatible. Unfortunately not! The lack of Flash and Java on the iPhone and iPad means a large number of websites won't display properly. Having said that for the remaining websites Safari does do a very good job.

If you are willing to jailbreak your iPhone (bypass Apple's draconian app installation protection/stranglehold) then you can install Java, and all sorts of other wonderful apps that don't conform with Apple's 'policies'. It's simple and by far the best thing I ever did on my iPhone.

Having said all of that I have an iPhone and love it. It's just unfortunate Apple insist on trying to control and restrict everything.

The iPad is basically going to be a giant iPod Touch - so same restrictions and apps. It will be marvellous for browsing the web, watching videos, reading email/e-books and hopeless for much else.

englishal

22nd Feb 2010, 13:25

Another reason Android is superior to the Apple OS and perhaps one reason Apple will eventially sign their own death warrant?

ILOC

22nd Feb 2010, 13:40

Not that I ever thought I'd hear myself saying it, but...

Just wait for Windows Mobile 7. Microsoft have made a completely unprecedented move (in the history of Microsoft) and completely scrapped their existing Windows Mobile code and started from scratch.

The prototype phones they are showing around look like they are going to be really very good. They are taking a sensible middle ground in specifying quite tightly what hardware must be used for the phones but still allowing other manufacturers to produce them.

The interface looks really good - clean, fast. Still quite a few bugs at the moment but it's a very early prototype.

Don't even get me started on Microsoft's prototype Courier tablet, now that looks amazing.

God, I'm beginning to sound pro-Microsoft. Coat, hat.

IO540

22nd Feb 2010, 14:09

IMHO there is no handheld device, nor is there likely to be one, which does the whole job for GA preflight tasks.

I can get very basic weather data on my phone, but can't run any usable route planning app on anything that size.

One needs something bigger - a 7" screen or similar. Obviously not a phone, PDA or anything like that.

The Ipad is good for nothing other than a PDF browser - IF you can get a load of plates printed off to appropriately sorted PDFs. That's a possible EFB solution for IFR pilots, which are a small group.

I have played with loads of gadgets but no matter how I look at it, a small lightweight laptop is the way to go. With a GPRS/3G radio (which can be a bluetooth-connected mobile phone**) it actually does everything.

Funnily enough the Ipad's advert budget and fashionable following should result in a load of lookalikes from China but they will be normal 80x86 computers and thus far more useful.

The big issue with WM is that M$ do not offer any support or patches. They delegated this to the device manufacturers, who obviously washed their hands of customer support. Compaq, HP, Toshiba, Fujitsu, etc, never supported these products, giving rise to a raft of online forums where thousands of p*ssed off owners moaned about issues, and occassionally found fixes. This killed the PDA market well before "smartphones" came along.

We now have "convergence" of phones and PDAs (and low quality cameras) but I don't think this is relevant to GA preflight activities. In limited situations, a "phone" can be used to get taf/metars or even meteox.com radar data and such (my compact Nokia E51 can) and that is OK for a preplanned route, but flight plan filing is not usually a standalone task; one needs to plan the route somehow, with Eurocontrol validation if IFR, and all this extra stuff needs a laptop. So being able to run AFPEx on a phone is of use to some people some of the time, but usually only if they skip a lot of other important stuff.

** the advantage of using one's phone as the GPRS/3G radio is that you already have a SIM card in your phone, which you presumably "look after". Having another radio in the "portable device" is just a PITA because it's another SIM card to keep topped up, etc. Also many people have phones provided by their employer which is even better ;)

eharding

22nd Feb 2010, 15:49

Has anybody looked at the network traffic the AFPEx application generates in order to file a flight plan? - is it via HTTP, or some custom protocol? Does it work behind corporate firewalls?

The decision to deploy this thing as a Java download smacks of extreme high-order muppetry.

kui2324

22nd Feb 2010, 15:57

eH - if your corporate IT police have dictated you can't download any applications/files (like ours have) then you may well not be able to run it.

Which is a complete pita when it comes to skiving off for a quick flight. When we are forced to use it for booking out courtesy of the upcoming NATS cost savings (and I do feel for the people who are losing their jobs over this) we will either have to hope the local handling agents computer is working or take a laptop to run it and use their wi-fi.

IO540

22nd Feb 2010, 17:43

Has anybody looked at the network traffic the AFPEx application generates in order to file a flight plan?

I did comparisons for a 'typical' flight plan filing session

Homebriefing 1.4MB
AFPEx 0.4MB
EuroFPL 0.1MB

AFAIK, AFPEx is all over port 443 (HTTPS). Never had any trouble running it, over mobile internet or anything else.

You have an email.

FlyUK73

22nd Feb 2010, 19:32

1) a lot of people download from http://www.flightplanningonline.co.uk/ which then changes the URL to one of the others - which one, seems to vary

It's the servers carrying out load sharing, if 2 and 3 have more users the call is directed to 1.
2) why download from all three?
On startup the cached version on your local computer is examined by the server to ensure it matches what is expected, if the server doesn't see a match it forces download of a new one. A download from ts1 has a different point of origin from one downloaded from ts2, therefore it is stored in cache differently.
3) will you publish an update schedule?
I just did. ;)
4) if one is running the cached version, by executing ats.xjnlp.jnlp loader rather than going to the website, the ts1/ts2/ts3 server selection appears to be determined by the loader file; mine contains ts3 in one place and all three lower down
Then you will always download from ts3, the risk is that the ats.xjnlp.jnlp loader may change, which means you may have issues if try to use the stored version on your desktop. The index page including the webstart file is about 70kb, switch images off on your browser and you are down to about 5k. A better way of avoiding the index page download is to put a shortcut to https://ts1.flightplanningonline.co.uk/ATS/ats.xjnlp directly on your desktop ensuring a valid webstart file (about 1k) is downloaded every time. The problem with doing this is that if everyone saves ts1 on their PC as a shortcut, all that money spent by NATS on load sharing implementation goes straight out of the window.

Bear in mind also, that if the implementation was not Java your bandwidth would be much much more, as an active html page with server calls to validate data on the fly would require more interaction. Your local copy of AFPEx already contains all the data needed for validation of the various elements of the forms, standard routes for IFR flights, etc.

IO540

22nd Feb 2010, 19:58

OK, good.

Some random observations:

From talking to many, I suspect most people are unable to execute a file called ats.xjnlp - presumably due to a missing association. That's why, when I downloaded mine (from the Login prompt on your website) I called it ats.xjnlp.jnlp.

Server load sharing: would you not find that if you drastically reduced the full application download incidence, your server bandwidth would go way down? In the bad old days your servers must have been running flat out serving all those 3.5MB chunks. There aren't that many pilots with UK addresses :)

Standard routes: how are these used? IFR routes will always be pre-validated via IFPS, otherwise the FP gets a REJ. The majority of IFR routes flown "for real" are not out of the SRD; SRD routes just take you for a scenic flight around Paris with a 200nm radius :)

eharding

22nd Feb 2010, 21:54

Bear in mind also, that if the implementation was not Java your bandwidth would be much much more, as an active html page with server calls to validate data on the fly would require more interaction

Sorry, that just doesn't sound true - what sort of validation is going on that would require AJAX interactions that would compare to a 3.8 Java Mbyte download every month or so?

A more likely explanation is 'we had this Java application developed for inhouse use, and decided that rather than build a scalable web application for external use, given the likely number of users, we'd foist the Java application on them instead'...and that would be a reasonable explanation - but don't try and bulls**t anyone into thinking this is a better solution than a pure browser-based implementation.

Even if we accept that it is more efficient to have the validation done locally, why does the *whole* thing have to be downloaded to reflect changes in the data? - unless you're constantly adding functionality with every release, then the changes to the validation data should be an incremental download - at least, it should be in anything with a remotely decent architecture.

jonkil

22nd Feb 2010, 22:43

Sorry Fellas, wrong Forum I'm in, thought I was in the forum about flying, sorry again for logging into a GSM forum ! Anyone fly in here ? :rolleyes:

eharding

22nd Feb 2010, 22:53

Sorry Fellas, wrong Forum I'm in, thought I was in the forum about flying, sorry again for logging into a GSM forum ! Anyone fly in here ? :rolleyes:

Apologies - and now back to our normal Pprune fare:

....anyway, that plastic C42 toy you fly - how long does it take to wind up the rubber band, and what happens if you wind it the wrong way? - also, in the event of a prop-strike, does the prop stop dead and the rest of the airframe spin wildly around it?

You see, you feel at home already.

flybymike

22nd Feb 2010, 23:19

Thank God.
Someone who speaks English....

bookworm

23rd Feb 2010, 07:20

FlyUK73, thank you, your information on the architecture is very helpful.

Bear in mind also, that if the implementation was not Java your bandwidth would be much much more, as an active html page with server calls to validate data on the fly would require more interaction. Your local copy of AFPEx already contains all the data needed for validation of the various elements of the forms, standard routes for IFR flights, etc.

Validation could be done in Javascript in the browser though, couldn't it? The issue is about where the code resides, not what language it's written in. And storing the standard route catalogue at the client is hardly efficient.

Surely the reason for using Java is that this was the way the COTS product worked. NATS wasn't going to develop bespoke software for this purpose, was it?

IO540

23rd Feb 2010, 09:24

What does the SRD data do in the client application (or anywhere at all)?

There is no IFR route planning facility I know of, anywhere in all of this.

FlyUK73

1st Mar 2010, 10:56

From talking to many, I suspect most people are unable to execute a file called ats.xjnlp - presumably due to a missing association. That's why, when I downloaded mine (from the Login prompt on your website) I called it ats.xjnlp.jnlp.

That is correct, the helpdesk gets lots of calls about this.

Server load sharing: would you not find that if you drastically reduced the full application download incidence, your server bandwidth would go way down? In the bad old days your servers must have been running flat out serving all those 3.5MB chunks. There aren't that many pilots with UK addresses http://images.ibsrv.net/ibsrv/res/src:www.pprune.org/get/images/smilies/smile.gif
AFPEx doesn't only have load sharing for bandwidth sharing, it's also for contingency. The 3 server layout allows for a "majority decision" environment where if one server shows an error the other two can be used to restore it.

Standard routes: how are these used? IFR routes will always be pre-validated via IFPS, otherwise the FP gets a REJ. The majority of IFR routes flown "for real" are not out of the SRD; SRD routes just take you for a scenic flight around Paris with a 200nm radius http://images.ibsrv.net/ibsrv/res/src:www.pprune.org/get/images/smilies/smile.gif
These are the routes contained with the the UK SRD, which are NATS' preferred IFR routes updated monthly and uploaded to the server.

Sorry, that just doesn't sound true - what sort of validation is going on that would require AJAX interactions that would compare to a 3.8 Java Mbyte download every month or so?
Nearly every item in every form is validated; there are many forms on AFPEx not just the flight plan form. I'm not going to extrapolate the values for you, but in terms of reliability on low bandwidth lines, a single prevalidated message is far more efficient/quick than a huge number of Ajax calls. Also, if the server is unavailable for short periods, local validation can continue.

A more likely explanation is 'we had this Java application developed for inhouse use, and decided that rather than build a scalable web application for external use, given the likely number of users, we'd foist the Java application on them instead'...and that would be a reasonable explanation - but don't try and bulls**t anyone into thinking this is a better solution than a pure browser-based implementation.
So many assumptions; no facts. I won't rise to your hostility, it's not worth the wear on the keys of my keyboard.

Even if we accept that it is more efficient to have the validation done locally, why does the *whole* thing have to be downloaded to reflect changes in the data? - unless you're constantly adding functionality with every release, then the changes to the validation data should be an incremental download - at least, it should be in anything with a remotely decent architecture.
Again, assumptions. When the version of software changes it is good (and common in the industry) practice to install the whole application again. 3.8mb is smaller than most OS security patches so hardly a major download. AFPEx has made many changes to the software recently, mainly because of feedback from users, which is a good thing I'm told.

Validation could be done in Javascript in the browser though, couldn't it? The issue is about where the code resides, not what language it's written in. And storing the standard route catalogue at the client is hardly efficient.
It could, but there are many fields that need to be checked semantically and syntactically and the Javascript validation would fail on the first hurdle if it is switched off at the browser. The SRD is currently is downloaded on the fly, so if you don't use it you don't download it.

Surely the reason for using Java is that this was the way the COTS product worked. NATS wasn't going to develop bespoke software for this purpose, was it?
Yes, the COTS product was Java and for many reasons it was chosen as a suitable interface. Bespoke software is a thing of the past for most smaller projects, especially with so many good applications already out there.

What does the SRD data do in the client application (or anywhere at all)?

If you look under View, Preferential Routes on the APFEx terminal you will find them. Bear in mind that this is set to be downloaded as required so when you view that menu there will be a large download.

I'm happy to reply to most questions, but this is not in an official NATS capacity and I most certainly will not reply to hostility either toward me or NATS as I do this in my own time to try to help as best I can. :)

IO540

1st Mar 2010, 18:45

Your replies here are much valued, FlyUK73 :ok:

These are the routes contained with the the UK SRD, which are NATS' preferred IFR routes updated monthly and uploaded to the server.I am only a mere private IFR pilot but IMHO almost nobody flies SRD routes. Many of them are unworkable due to poor efficiency, and anyway most IFR enroute controllers don't operate them. Them seem to be mostly the end product of jostling for airspace by the diverse groups that own airspace (the military being a principal player, and much of the routing nonsense is to avoid huge chunks of empty military airspace).

It would thus seem to me to be a less than optimal allocation of resources to not have AFPEx as a simple website, for the sake of this kind of facility.

AIUI, most commercial IFR users get dedicated departments (or flight support services such as Jepp) to work out airway routes for them, and private IFR pilots use recently developed routing tools. So I don't see much actual real usage for standard route data in a tool whose user profile is that of AFPEx. Especially as the routes are UK only.

3.8mb is smaller than most OS security patches so hardly a major download.True; however this remains a major issue for mobile internet users. The only ones who won't care will be ones who never fly abroad (and don't pay roaming charges) or ones on £40+/month contracts (which comes with enough "free" roaming data included).

Anybody with a laptop with mobile internet will very thoroughly turn off all windoze and other updates otherwise.... bang there goes your whole SIM card account; on a fast 3G connection you blow money away at anything up to about £40/minute :)

AFPEx is now a very good tool but the incidence of the whole application download needs to be somehow controlled, for "us" travelling pilots.

Also, could you please lengthen the login session timeout? It is only so many minutes. I don't think the short timeout aids security because if the machine is not physically secure, there is no security anyway because it takes only seconds to install a keylogger... (the banks know this too but cannot admit it :) ).

S-Works

1st Mar 2010, 19:55

AFPEx really needs to be a straight HTML tool with no downloads and be truly platform agnostic to be of proper value.

As IO points out the cost of operating it on roaming GPRS/3G is expensive and it ties the app to laptop devices rather than mobile devices.

LH2

2nd Mar 2010, 02:16

AFPEx really needs to be a straight HTML tool with no downloads and be truly platform agnostic to be of proper value.

HTML5 anyone?

(when eventually agreed upon that is :bored:)

(and btw, Java is so 1990's :p Decent if not quite novel idea, but horrible kludge of an implementation IMO)

(and for a last set of parentheses, may I suggest using deltas [binary diffs] for updates? I don't think nowadays "updating the whole application" is taken literally, even if conceptually true... certainly not in my domain)

FlyUK73

2nd Mar 2010, 07:38

I am only a mere private IFR pilot but IMHO almost nobody flies SRD routes. Many of them are unworkable due to poor efficiency, and anyway most IFR enroute controllers don't operate them. Them seem to be mostly the end product of jostling for airspace by the diverse groups that own airspace (the military being a principal player, and much of the routing nonsense is to avoid huge chunks of empty military airspace).

It would thus seem to me to be a less than optimal allocation of resources to not have AFPEx as a simple website, for the sake of this kind of facility.

AIUI, most commercial IFR users get dedicated departments (or flight support services such as Jepp) to work out airway routes for them, and private IFR pilots use recently developed routing tools. So I don't see much actual real usage for standard route data in a tool whose user profile is that of AFPEx. Especially as the routes are UK only.

They are a required part of the system for some customers. AFPEx is about pleasing as many users as possible as much as possible, not all users always. It's a fact of software development today that the sheer range of operating systems, browsers and other settings/requirements within the user pool makes it impossible to catch 100% of users 100% of the time.

AFPEx really needs to be a straight HTML tool with no downloads and be truly platform agnostic to be of proper value.

As IO points out the cost of operating it on roaming GPRS/3G is expensive and it ties the app to laptop devices rather than mobile devices.
HTML5 anyone?

(when eventually agreed upon that is http://images.ibsrv.net/ibsrv/res/src:www.pprune.org/get/images/smilies/wbored.gif)

(and btw, Java is so 1990's http://images.ibsrv.net/ibsrv/res/src:www.pprune.org/get/images/smilies/tongue.gif Decent if not quite novel idea, but horrible kludge of an implementation IMO)

This is true, but there are many functions that can't be implemented with quasi-live html on older browsers. Many of the AFPEx users are still running windoze XP with IE6 and refuse categorically to move out of that envelope under the "it has worked for me so far" umbrella.

(and for a last set of parentheses, may I suggest using deltas [binary diffs] for updates? I don't think nowadays "updating the whole application" is taken literally, even if conceptually true... certainly not in my domain)
Asking our software developers to implement binary diffs for a 3.8mb application to benefit mobile users would probably be possible but most certainly very expensive as it is a significant branch variation on a COTS product. Not really viable considering mobile users are a miniscule percentage of AFPEx users. International mobile AFPEx users are like mac users; a very vocal minority.

The host nation should provide you with plan filing facilities though, usually through the local flight centre or departure tower. Alternatively you can send both legs before departure and activate them as required.

IO540

2nd Mar 2010, 07:42

Alternatively you can send both legs before departure and activate them as required.

How is that done?

FlyUK73

2nd Mar 2010, 09:00

You can send the outbound and inbound leg for a trip to france at the same time, for example, and ask the tower to send a DEP message (activation) on departure from the UK and then ask the French to send a DEP on your departure from their airfield. As long as they were all addressed correctly everybody should have a copy of your plan and know which plan you are referring to.

Messages for onward legs can be also sent at the same time for three leg journeys, four leg, etc.

IO540

2nd Mar 2010, 10:09

In that case, what time/day of departure should I specify? I cannot file a FP without giving these details.

I realise I can file a FP for some date up to 5 days ahead (IFR) and then phone your ever helpful person at Swanwick and ask him/her to re-file the FP with today's date etc, but I don't think that's quite what you meant. There are at least two issues with that:

1) a Eurocontrol route which validates for say Friday this week may fail to validate if re-filed for today 3pm - this one has caught me a number of times and each time was at the most awkward situation possible (the fact that one is making a phone call to Swanwick implies that one's access to "IT" is severely limited :) )

2) to some extent, in some places, a filed FP acts as PPR/PNR

dublinpilot

2nd Mar 2010, 10:44

I understand the wish to ensure that users stay up to date with new version. However is it really essential that they do that straight away?

Would it not be possible to allow users 30 days to update, or x number of log ins. During this period they could be reminded of the need to update. After the end of it, then you would have to update before being able to continue.

That would ensure that users did stay up to date, but allow them the option of choosing to do so when connected to a non gsm network.

Workable or not?

heinke

2nd Mar 2010, 19:27

Sorry guys, but an update has to be deployed across all 3 servers and running two different versions is not feasible. However, we will look at a better way of notification for software updates in order to give you a chance to get the update before departing from home.

On the JAVA subject, as FlyUK73 said, that was what was on the market at the time. However, that doesn't mean to say that we don't listen and don't look at options on how the system can evolve, including using a non-Java based application.

That's not a guarantee that it will change and if it did, it won't be overnight. But, never say never :)

IO540

2nd Mar 2010, 20:02

I would not write off mobile users as a small group.

A mobile user is any pilot who has filed a flight plan at home, flown somewhere, stayed there doing some variable-time task (so he could not file the return flight plan from home), and then he has to file the return flight plan using some mobile means.

And somebody flying a multi-leg trip will definitely not be pre-filing.

It's of course true that there is wifi, internet cafes, etc. But things have moved on since the heyday of unsecured wifi and - where you can get a connection at all, which is basically nowhere outside city centres i.e. most airports!! - the whole business has become a giant ripoff, with £20-40/day billing and potentially recurring CC charges. Internet cafes are the last place you want to search for in some strange town, and most of them stink of fag smoke, never mind the smashed up keyboards. And one cannot run the AFPEx Java app on a typical locked-down cafe computer, which leaves own-laptop connection, and I know only too well that most cafes don't allow a laptop connection. All doable of course (cafes and bars with wifi etc) but what a hassle.

On more than one occassion (like landing somewhere where they won't sell you avgas, alleged lack of PPR, etc) I have had to file a new FP from the cockpit (on GPRS/3G obviously - no wifi on the apron).

That leaves the departure airport, but filing a flight plan the old way (handwritten form) can be another hour wasted, messing around a non English speaking airport. Once one gets out of the English-fluent countries, at most "international" airports one is hard pressed to find anybody who speaks English, and in that I include the "tourist information" desk :)

This is why, 99% due to the "application download" uncertainty, I still maintain a 37 euro/year Homebriefing.com account, but it almost never gets used because there is EuroFPL (which only does IFR which is no good for 99% of UK private pilots). Also HB have trashed their website by using some trendy designer; 2MB of data last time I checked.

The other 1% is that AFPEx only just about runs on GPRS, and GPRS represents the vast majority of mobile data access; 3G has poor coverage outside city centres etc. I was running it on GPRS today; it did hang in there but only just. I think the timeouts need to be a bit longer.

One could argue mobile FP-filing users are a small group, but FP-filing pilots are a tiny group anyway; you don't "need" FPs for the UK. Yet plenty of people do file flight plans... enough to create work for loads of people in the now-closed FBUs... (reportedly 3000 flight plans per month) and they must be going somewhere.

Anway I know I've ranted on about this enough, and it's good to hear you are listening :) :ok:

Mac users are a totally different group - purely fashion conscious people with loads of money :) :)

LH2

3rd Mar 2010, 01:14

FlyUK73

Just for clarification, can you give us an idea as to your role in the AFPEx team? This is just so that your comments can be put in some context.

At first I assumed you were a developer, but having read this thread a bit more attentively it looks to me like this isn't the case. Project manager or team leader with little or no IT background perhaps, if I may take a guess? Again, the only reason I'm asking is to get a better perspective.

Some comments follow:

IE6

This is what told me you're not keeping up with current developments in the IT world.

to implement binary diffs [....] is a significant branch variation on a COTS product

This is completely orthogonal to product development. It's on the same level as deciding whether to package it in a green or in a blue box.

mobile users are a miniscule percentage of AFPEx users

Mobile computing is the way things are moving. That's one demographic you need to set your eyes on, not IE6 users. I suggest you talk to someone knowledgeable on the current (and developing, as always) state of play in IT or your product will be dead in the water in the next 18 months.

International mobile AFPEx users are [....] a very vocal minority.

Possibly because the product is so much more valuable to them?

The host nation should provide you with plan filing facilities though

"Should", as you say. That does not always happen--even when not flying internationally.

[ As an aside FWIW, my own solution is to carry a (borrowed) telephone which I use to call one of the French BRIAs (regional flight information and assistance centres), regardless of which country I'm flying in. They are fully competent and very efficient at doing what their name implies, i.e. providing information and assistance, including NOTAM and weather briefings, consulting foreign AIPs, and of course, filing flight plans. Their help has been invaluable on many occasions. ]

It's a fact of software development today that the sheer range of operating systems, browsers and other settings/requirements within the user pool makes it impossible to catch 100% of users 100% of the time.

That is incorrect--or rather, your focus is wrong. You can catch most of the users, most of the time, and even keep up as the market and technology evolves. In fact, you can do that at very little cost for your organisation.

How? Publish the protocol your application uses to communicate with its servers, and let third party developers work for you, for free, by creating AFPEx clients for their platforms and demographics of choice. That's good enough for the market leaders, and it's good enough for fringe players too. Matter of fact, if your product is worth anything it's only a matter of time before someone reverse engineers it, so save him the trouble.

Veeeffarr

3rd Mar 2010, 01:55

S-Works

3rd Mar 2010, 08:57

An iPhone/iPad version would be amazing. However an HTML version is really the way to go. There is no reason at all for using the JAVA client.

It is not rocket science, all people really want is a quick and simple way of filing a flight plan!! We don't need all the fancy messaging services of the AFPEx tool in reality.

As someone who files many flight plans, I would just love a web page with a standard flight plan form on it that has the addressing in drop down boxes and you just fill it in and click send, then check for the ACK. Or even get the ACK by email.

Assuming that mobile users are a minority is breathtakingly arrogant. They are the MAJORITY, it is just the service drives us to fixed platforms and that makes you blind to it.

God knows why it has to be so difficult.

IO540

3rd Mar 2010, 10:13

Check this out NAIPS for iPhone (http://naips.wordpress.com/) This works for the iPhone to file flight plans etc etc here in Australia. The author might be prepared to do a little development work to get it to work with AFPex. Or someone could buy this and use it as the basis of their own European version.

This looks nice; however it's not apparent whether the site this accesses is HTTP or HTTPS.

If the former, "anybody" can knock up such an application. Some websites do a lot of spurious token exchanges to prevent "scripting" but it never takes more than a few hours to work it out.

If the latter, it could take a huge amount of work. Not with an HTTPS browser (which uses standard protocols) but with a custom Java app like here. But the real issue, IMHO, is that NATS would pull the facility if somebody did this. It would have to be done with their approval.

It seems obvious to suggest that a cut-down version of the app, doing just FP filing with just the ICAO form and nothing else, would be useful to many pilots. This I am sure is true, and maybe NATS should examine that possibility. Like I said, AFPEx has dragged a lot of apparently totally non IT literate pilots out of the woodwork and they would appreciate a dead simple user interface.

However, some of the other features are dead handy e.g. free text AFTN messages, and the ability to delay flight plans. And if one has enough functionality for that (delaying largely implies retrieving the old one and editing it, though this isn't strictly necessary) one is practically looking at the existing app as it stands.

FlyUK73

3rd Mar 2010, 20:25

In that case, what time/day of departure should I specify? I cannot file a FP without giving these details.In theory, you should be able to plan and submit up to 5 days in advance, but if the route is not available on the day it is beyond all but Eurocontrol's control. Many airlines use RPLs that are planned months in advance, so they must find a way around it.

I would not write off mobile users as a small group.I don't think I said that, it just makes common sense to take care of the bulk of the users then work on the mopping up the rest.

Just for clarification, can you give us an idea as to your role in the AFPEx team? This is just so that your comments can be put in some context.

At first I assumed you were a developer, but having read this thread a bit more attentively it looks to me like this isn't the case. Project manager or team leader with little or no IT background perhaps, if I may take a guess? Again, the only reason I'm asking is to get a better perspective. I feel that my role within NATS is not relevant to this conversation.

This is what told me you're not keeping up with current developments in the IT world.Assumption.

This is completely orthogonal to product development. It's on the same level as deciding whether to package it in a green or in a blue box.AFPEx isn't a NATS only product, asking the developer to change something only NATS wants will create a software branch that NATS will have to pay for. That's the nature of COTS. Orthogonality is irrelevant.

Mobile computing is the way things are moving. That's one demographic you need to set your eyes on, not IE6 users. I suggest you talk to someone knowledgeable on the current (and developing, as always) state of play in IT or your product will be dead in the water in the next 18 months.I'm sorry, but that sounds too patronising to warrant a reply.

Possibly because the product is so much more valuable to them?This may be the case, but an unhappy vocal minority is better than an unhappy vocal majority. Developing/buying software that pleases everyone is IMPOSSIBLE, even Redmond have failed so far.

"Should", as you say. That does not always happen--even when not flying internationally.That's down to poor will, lack of training or plain and simple pigheaded laziness from the ATSU.

[ As an aside FWIW, my own solution is to carry a (borrowed) telephone which I use to call one of the French BRIAs (regional flight information and assistance centres), regardless of which country I'm flying in. They are fully competent and very efficient at doing what their name implies, i.e. providing information and assistance, including NOTAM and weather briefings, consulting foreign AIPs, and of course, filing flight plans. Their help has been invaluable on many occasions. ]You should call our helpdesk, they are quite helpful too within the scope of their role.

It's a fact of software development today that the sheer range of operating systems, browsers and other settings/requirements within the user pool makes it impossible to catch 100% of users 100% of the time. That is incorrect--or rather, your focus is wrong. You can catch most of the users, most of the time, and even keep up as the market and technology evolves. In fact, you can do that at very little cost for your organisation.Your statement confirmed my statement.

How? Publish the protocol your application uses to communicate with its servers, and let third party developers work for you, for free, by creating AFPEx clients for their platforms and demographics of choice. That's good enough for the market leaders, and it's good enough for fringe players too. Matter of fact, if your product is worth anything it's only a matter of time before someone reverse engineers it, so save him the trouble.Allowing someone direct access to the AFTN network in an uncontrolled manner would be reckless considering the type of traffic that goes across it, I'm not sure CFMU would appreciate messages about Viagra and Penis Enlargement. Another reason NATS uses a Java application is to prevent reverse engineering, if you can crack the encryption I think the FBI would like a word. ;)

Assuming that mobile users are a minority is breathtakingly arrogant. They are the MAJORITY, it is just the service drives us to fixed platforms and that makes you blind to it.It's not arrogant, AFPEx was never intended for use on mobile devices and therefore was not designed for mobile devices. If you can get it to work on your 3G laptop then that is a bonus, but this was not the original design specification. Before AFPEx those that didn't use homebrief/olivia only had the option to fax/call or dictate over RT their plans, now there is another option that thousands of users are happy with.

If the latter, it could take a huge amount of work. Not with an HTTPS browser (which uses standard protocols) but with a custom Java app like here. But the real issue, IMHO, is that NATS would pull the facility if somebody did this. It would have to be done with their approval.NATS is duty bound by ICAO to protect the AFTN network. Connecting to AFPEx in a non-approved manner would be considered malicious.

It seems obvious to suggest that a cut-down version of the app, doing just FP filing with just the ICAO form and nothing else, would be useful to many pilots. This I am sure is true, and maybe NATS should examine that possibility. Like I said, AFPEx has dragged a lot of apparently totally non IT literate pilots out of the woodwork and they would appreciate a dead simple user interface.Things do change after user feedback, NATS has responded to user input and adapted the application accordingly. This will continue throughout the life of AFPEx so as some say, never say never. :ok:

IO540

3rd Mar 2010, 20:53

In theory, you should be able to plan and submit up to 5 days in advance, but if the route is not available on the day it is beyond all but Eurocontrol's control. Many airlines use RPLs that are planned months in advance, so they must find a way around it.
And there was me standing next to a chap in the Eurocontrol facility at Brussels, in the actual room with "IFPS" on the door, with him telling me how much hassle they have with airlines submitting repeating flight plans, which work on the Monday, and break on the Tuesday, and IFPS staff then have to manually fix up the routings on Tuesday, Wednesday, Thursday, Friday, Saturday.... they will have told the airline to fix the routing by about Wednesday and by the weekend IFPS chucks the whole thing out and the airline's OPS department has to produce a routing which validates on the Monday again........ and then the process repeats :)

Fixing broken routes is a marvellous job creation scheme at IFPS, but one can bet that the one time you really are up the **** creek and really want the RMK IFPS REROUTE ACCEPTED to work, IFPS will wash their hands of it (as they are absolutely entitled to do).

I am no "sky god" but having been caught by this a few times I would never file a flight plan 5 days in advance and

a) expect the route to still validate when I change the DOF/ after say 3-4 days (especially if I change the DOF/ between a weekday day and a weekend day, which changes many airways)

b) expect to be able to depart as planned after such a long time (weather etc) :)

The only way to work the IFR system reliably is to be able to, on the day of the flight or shortly before, develop a valid route, and file the flight plan with it. Anything else is a bonus, and often breaks.

That is why a well usable mobile-internet application is desirable. It's not hard to do, at all. It should have just been in the original specification ;)

You are nearly there now; you just need to sort out the version control and publish a fixed update schedule, say 1st of each month, not force a download of the update for the whole of the following month, and for each update publish which features of the previous version will not continue to work after the update date (for people who are unable do do the download when they are away). Downloading 4MB is trivial if people know when they need to do it.

LH2

4th Mar 2010, 00:21

I love the can do attitude :}

IO540

5th Mar 2010, 06:31

I ran the (hibernated) Java app this morning, to see if it is asking for a software update, and while it did ask, the old one apparently continues to work i.e. no update is forced. This is good.

However, when I came to download a fresh one (by running the little Java loader that I always use) it didn't download a fresh one but instead started the cached version.

Going to the NATS website (using Firefox) and using the Login method does download the fresh app.

I also noticed that the Java loader (that gets downloaded when one goes to the URL) changed this morning between about 8am and about 9am, from TS1 to TS3. One of these downloaded a fresh app, while the other one started the old cached one.

So it looks like NATS are doing their load sharing by dynamically editing the loader app.

This presumably illustrates FlyUK's advice to start the app by going to the www.flightplanningonline.co.uk (http://www.flightplanningonline.co.uk) (NOT the one with ts1/ts2/ts3 in it) URL rather than by running the Java loader - at least, I guess, when an update is suspected and you really do want the latest version.

I do have an issue with a fresh install of IE8 on a laptop - it doesn't know what to do with the file even though that computer has been used with AFPEx many times. I suspect a filetype association issue; this may be a common thing.

I also noticed this morning that the NATS server is far faster than before; downloaded the ~3-4MB app in about 10 seconds.

derekf

5th Mar 2010, 14:29

Try reinstalling Java and it might recreate the associations.

IO540

5th Mar 2010, 14:52

Doesn't seem to, not under windoze anyway.

derekf

5th Mar 2010, 15:10

Try calling AFPEx help desk - I'm sure other people have this problem and it would be interesting to see how well they deal with this sort of query.

IO540

5th Mar 2010, 15:26

Not an issue for me personally; I don't use IE for anything serious, and I simply rename the java loader from ats.xjnlp to ats.xjnlp.jnlp.

I recall, in the earlier days of AFPEx, someone developed a hack for the loader file which avoided the every-time download, and it was found that even very old versions of the main app continued to work. I guess that if you only ever file flight plans, only a very small part of the whole protocol gets exercised.

mm_flynn

6th Mar 2010, 06:58

In theory, you should be able to plan and submit up to 5 days in advance, but if the route is not available on the day it is beyond all but Eurocontrol's control. Many airlines use RPLs that are planned months in advance, so they must find a way around it.

Interestingly I was at a conference on flexible use of airspace and one of the airlines presented on their view. Which broadly was :yuk::eek::mad:.

They had accidentally created a route with a CDR2 segment in it (live at the time of the flight), however, they received a slot delay which then put them outside the CDR2 time and bang the flight plan was dropped from the system. Mad panic, ops office re-files, longer route more fuel - Oh No back to the ramp for fuel!!

Fortunately in this case the pilot had demanded a few extra tonnes of fuel so was still OK.

The formal conclusion of the presentation (remember this is a large airline presenting at a EuroControl conference to a bunch of other airlines and flightplan service providers)

NEVER EVER EVER plan a route transiting flexible use airspace. And even then as IO points out the RPL still have an amount of rework in them.