sims wrote:
The error clearly says that the DCT limit below FL325 is 0. The performance of the aircraft has nothing to do with this, as you are at FL120, so you always climb and descend below FL320. Rocker Route is perfectly valid here.
With a little bit of extra understanding of the Eurocontrol system and the restrictions at play here, your statement would be less simplistic and wrong…
The restriction referenced at the beginning of the thread (LY1A) has a list of allowed exceptions to the DCTLIM=0 rule and the one found in the route was one of them at the time. However, it had an altitude limit (I believe FL115 at the time) and in this specific case, omitting the 4D profile information made the Eurocontrol profiler believe that the aircraft descended earlier/faster and was outside the allowed altitude band on the DCT. The error message for the restriction is very generic, chosen by the author.
The IFPS business can be complex and full of edge cases.
achimha wrote:
The restriction referenced at the beginning of the thread (LY1A) has a list of allowed exceptions to the DCTLIM=0 rule and the one found in the route was one of them at the time. However, it had an altitude limit (I believe FL115 at the time) and in this specific case, omitting the 4D profile information made the Eurocontrol profiler believe that the aircraft descended earlier/faster and was outside the allowed altitude band on the DCT. The error message for the restriction is very generic, chosen by the author.
Thanks for the explanation. I changed my aircraft in RRouter from SR22 to a t.prop and got this route which is valid: MIL1G MIL N134 KOR L613 YNN L611 RODON DCT TIBRI L187 MOKUN MOKUN3A (at the same FL140) – that successfully traverses that DCT that fails with SR22. So indeed the error message is misleading (and I bet it comes from Eurocontrol?). On that note, autorouter.aero gives a longer route: MIL1G MIL N134 KOR L53 GARTA V62 YNN L611 RODON DCT TIBRI L187 MOKUN MOKUN3A.
Oh my… Way too complex :)
sims wrote:
On that note, autorouter.aero gives a longer route: MIL1G MIL N134 KOR L53 GARTA V62 YNN L611 RODON DCT TIBRI L187 MOKUN MOKUN3A.Oh my… Way too complex :)
No, even more complex 
The route you quoted from RocketRoute involves a CDR 2, i.e. a segment that is only available at certain times. It turns out that the departure time you planned with autorouter has it closed: PROF199: KOR L613 YNN IS A CLOSED CDR 2 IN FL RANGE F115..F245. Therefore autorouter finds another route. If you try it for the night, autorouter will come up with the shorter route.
achimha wrote:
It turns out that the departure time you planned with autorouter has it closed:
You are correct; now I used SR22 both in AR and RR and routed the same pair for 1800Z today.
RR returned a route with 9% overhead, AR got a route with 10% overhead, but including SID/STARs.
RR route: N0168F120 DCT MADEX L53 OLGAT/N0168F130 L53 OKIMO A48 BEVIS
AR route: N0177F070 MADEX1W MADEX L53 AKORO/N0175F090 L53 ELVAS/N0173F120 L53 GARTA V62 YNN L611 RODON DCT TIBRI L187 MOKUN MOKUN3A
When I add SID (MADEX1W) and STAR (BEVIS2A) in RR I get 14% overhead, but RR route is more leveled and goes higher. I am not sure if the more overhead at a higher FL is better or worse than less overhead on a lower FL though…
I don’t share tracking links with my family/friends neither I invite them to follow me on FR24. I simply can be too stressful, especially when weather and wind don’t cooperate. When I land I send the messages to all that should be informed.
Today, I had to divert and the autorouter track showed the whole flight including the diversion.
Yesterday I had 2 flights planned pretty much back to back:
1: LFPN → LFOP. Filed with a huge dogleg, EET 55 min. I estimated this to take closer to 25-30 min.
2: LFOP → EGKB, Which would likely have a take off time about 0-5 min after the the other flight plan was closed (I was only stopping for customs and LFOP can be very helpful).
As some of you might know, Autorouter doesn’t allow filing overlapping plans. I’ve done:
File 2 for the time I expect.
File 1 for enough time (in that case >1h before EOBT of 2), and then delay 1 to actual time.
The inverse, filing correct time for 2, later than expected time for 1, and bringing forward 2 (before you fly 1), doesn’t work, as the bringing forward cancel and refiles. The cancel works, but the refile then doesn’t work because then it’s EOBT still falls during the filed time of 1.
Yesterday, I started receiving slot delays for 1 (12h delay, french ATC strike). I brought forward twice (1h before initially planned), and on second attempt didn’t get that delay message. Great! However, as I when in taxi to the airport (at that point, EOBT1 in ~35 min), I got a slot delay for 2 (same reason). I tried to bring forward, wasn’t able to bring forward enough, (as then the EOBT would fall withing the (super long) EET of 1), and wasn’t able to avoid the slot delay.
In the end, ATC was super helpful (even though it was “their” strike) and everything got sorted out, but I kept wondering that some of the unknowns would have been solved if I could have filed overlapping by “Confirmed it’s not a mistake”.
Not being able to file overlapping flightplans is not an autorouter restriction, but a Eurocontrol restriction.
Autorouter error
Hi Guys,
Happy new Year first of all!!
Can anyone help with the setup of autorouter. I have just set up a new aircraft, and when I click on routing all I get is this error: IcaoAtmosphere::altitude_to_density: altitude above model limit
And the auto routing will not even start.
This is set up for a jet with FL410 max altitude.
I have checked all the parameters and It still wont work..
Thanks
Why not contact autorouter support (top right-hand side corner – Support)?
