Chwinter,
Your BE36 issue is already logged with eurocontrol and they swear they will have it fixed in the next ARINC cycle. They seem to be having a string of changes where they pick the non turboed version of a type (like the BE36 which covers normally aspirated, turbo charged and turbo normalised). The work around is to file type zzzz and /TYP BE 36. Note the space between E and 3. This is needed to keep the system from recognising the type and hen reapplying the crippled performance model! (They did the same thing to commander operators a few months ago)
Peter,
FPP is crashing on that one due to a socket issue (which thanks to the emails people have sent with traceback info I hope I am finally resolving). It happens when the time out of the CFMU route proposal is just wrong. Hopefully new version on the weekend will resolve this.
Mike
Yes, and ideally we want the route with only the "bends" in the airways, so that we can enter the bending moments into our G430 for example (in case airways are not supported), right?
How reliable is it?
It works for me. I haven't done randomized testing; but Sjoerd and you keep finding challenging routing problems that helped me greatly finding corner case bugs :)
Feel free to try it for yourself to see how well it works for you
If somebody is going to do that, they will need to be fairly sure it works well.
There won't be a zero maintenance autorouter. Even if your software was bug free (chances are slim given the complexity of the problem), Eurocontrol's stuff is buggy enough to require the occasional workaround to be implemented.
Examples are:
eRAD generation is usually syntactically correct, but I have seen a few cases of semantic nonsense, some of them reported and fixed (after a couple of weeks)
end of last year, they had the 8.33kHz flag set incorrectly on many airspaces, and they couldn't get that fixed for several AIRAC cycles. Their "fix" was to tell the manual queue operators to accept flight plans with (only) 8.33kHz errors; so I had to implement an "ignore list" for 8.33kHz errors
This was one reason they started to hack their validation portal - to make it harder to script.
Are you sure about this? To me, it seems like their usual way of solving a problem in the most complicated way possible. If they did that for detecting "illicit activity" (whatever the definition), moving to a flash portal made things worse for them, because they now just see a web browser connecting, while before they could probably fingerprint protocol implementations.
I am not expecting anybody to discuss trade secrets
Trade secrets? In an open-source software? Difficult to keep 8-)
one could not download SIDs or STARs (that data is kept a commercial secret)
This is a bit of a weak spot. I don't have a SID or STAR Database. What I do is just connect all points within a certain distance (currently 40NM by default) as potential SIDs or STARs and then deduce from query results which are not.
This works reasonably well except for a few cases:
Paris region SID's/STAR's are really looooooong
If the only valid SID or STAR leads into the wrong direction, it will create a lot of queries to Eurocontrol. Tough cookies for them.
The router does have the SID and STAR connecting distance configurable, it can also be told explicitly which point to use.
They existed only as a lat/long.
They seem to be in the designated points database by now.
But there are still lots of points in the airway DB that cannot be flight planned, like "WIL10", which need to be deleted before filing.
Would your algorithm do a descent after a climb?
It can easily do that. It's not very eager, though, with the current performance model. The performance model currently models climbs and cruise, but doesn't give any credits for descent. If the airspeed isn't faster at a lower level, it won't want to descend.
It should however be easy to incorporate some sort of "discomfort factor".
There is also a need to be able to specify and file a very low level e.g. FL070 because some airways going back into the UK need that. You never actually have to descend in reality...
If remaining on a higher level means a longer detour than the higher TAS would compensate, then it will descend.
Except the vast majority of IFR pilots cannot enter airways into their GPS, and a 100-waypoint plog is near-useless.
But the vast majority of GA pilots won't fly for 10 hours either. You'd have to break up the flight plan into parts; you'll have enough time during your 10 hour flight to enter the parts, it'll keep you awake :) And chances are, you won't need large parts anyway due to DCT's...
Filing a 100 wpt flight plan shouldn't be any issue, it's cut&paste at worst.
My ideal would be to export a flight plan to a storage device, and import it into the panel avionics. This works somewhat with a G1000, but their parser for their proprietary flight plan format is so bad it will even choke on its own exported flight plans.
Of course, output options should be easy to add, if there's serious interest, such as expanding/collapsing airways, removing non-turning points without and possibly with airway changes, export without level changes...
I personally don't use and don't particularly like FightStar, I've become accustomed to the EAD plates, and apart from the plates I don't see FlightStar adding any value
Are you sure about this? To me, it seems like their usual way of solving a problem in the most complicated way possible. If they did that for detecting "illicit activity" (whatever the definition), moving to a flash portal made things worse for them, because they now just see a web browser connecting, while before they could probably fingerprint protocol implementations.
Yes I am very sure about it.
They implemented that change very rapidly after one developer ran some intensive validation activity.
If the airspeed isn't faster at a lower level, it won't want to descend.
How can you tell?
I suppose there must be a performance table somewhere. It's my error for never using these features, maybe, because FPP has that too. Normally, IMHO, you should "drift down" to the "preferred" level once the higher MEAs have been passed, because the pilot will be filing the preferred level for a reason.
Reasons might be
But the vast majority of GA pilots won't fly for 10 hours either
No, but 5hrs is common enough, and one could easily be into 40 waypoints on that. Take the EGKA-LDLO I did last weekend.
Filing a 100 wpt flight plan shouldn't be any issue, it's cut&paste at worst.
True but you have to load it into your GPS. Unless you take the view (which some do take) that there is no point in bothering to enter more than the next one or two, but then what the lost comms scenario? I think one should be better prepared than that.
My ideal would be to export a flight plan to a storage device, and import it into the panel avionics.
You can do that with the GNS "W" boxes, using the Jepp Flight Plan Migrator (from Flitestar or maybe even Jeppview routepacks).
Some other firms (Chelton or Meggitt?) had this for years.
I personally don't use and don't particularly like FightStar, I've become accustomed to the EAD plates, and apart from the plates I don't see FlightStar adding any value
Flitestar doesn't have plates; it is a flight planner. If you install it on a PC on which Jeppview is also installed, you can access the plates from within both programs.
Flitestar is a clunky program which few people use nowadays. I would not push for any support for it (and none is needed) - other than the ability to copy/paste an airway route into it, for decomposition into waypoints, printing a plog and printing enroute strip charts. You can see the process here.
At the eye-candy level of new avionics, solutions are appearing e.g. the Aspen "Connected Panel" where an Ipad can send data to various stuff. Except that the vendors hate it and e.g. Garmin have just changed the crossfil protocol to block it.
Their crossfill protocol was the obvious way to electronically load flight plans and it was only a matter of time before somebody with an ARINC429-RS232 converter and a laptop running Teraterm reverse engineered it 
The problem with that is that as soon as you go public, they would seek to block it.
How can you tell?
There's a performance model
better MPG below FL170 (cannot reach operating ceiling at peak EGT, on any plane)
There's a switch to optimize for least fuel instead of least time
with an ARINC429-RS232 converter
Don't the Garmin boxes support crossfill over RS232 too? Or just ethernet these days?
Anyway, too bad my steam GPS doesn't support crossfill at all.
I experimented a bit with a "preferred level" metric. It is segment length based. Every segment length gets multiplied by a configurable value (currently 1.05) for each level it is off the preferred level, so the metric grows exponentially away from the preferred level. There's also a fixed penalty for each level climb (currently 10NM), and a bonus for each level descended (currently 3NM).
The result is this (1584NM): F120 HOLLY DCT BONDY DCT LONRU DCT GILTI L179 COA Y50 LUMEN Y50 GOLEX L607 SUXIM DCT AGBUL DCT OLIVI DCT RORAS DCT TAGIK DCT GUPIN DCT ABGAS DCT DETOB DCT MAH DCT VAVOR/N0163F140 M867 LOMRO/N0165F150 M867 NOKDA/N0163F140 M867 ABISO L608 DOL L868 GISER L862 BRD L995 KRK A14 MIL A10 XAVIS
You can do that with the GNS "W" boxes, using the Jepp Flight Plan Migrator (from Flitestar or maybe even Jeppview routepacks).
You can also do it with RocketRoute and the Garmin GNS/GTN/Flight deck products.
I don't have an iPad I use other than for jeppview, what route does your app give for EGTK to LEGE at FL270/280
You can also do it with RocketRoute and the Garmin GNS/GTN/Flight deck products.You can also do it with RocketRoute and the Garmin GNS/GTN/Flight deck products.
How is it done? (the interface, etc)
