New ATC and Airport Operations Application Testing

[Nemo 1,305]

I've tested the new build and can confirm that it works - I configured EDDF R07C (30%) and R18 (70%) for TakeOff;  R07L (40%) R07R (60%) for Landing. All worked out pretty well. This is the very first time that I saw a realisitc runway usage at EDDF. Thank you so much!

Regarding Taxi/Flaps, I saw only one a/c with Reverse Thrust confuration during taxi towards the runway.

Just one other question. During P3D start, the ATCAPI GUI loads in the background. It has several drop-down menus but nothing to choose from. Is this normal?

Edited December 9, 2020 by Nemo

[Nemo 1,305]

On 12/6/2020 at 6:35 AM, Capt. PERO said:

Awesome tool! If you guys are using SIMstarter NG P3D it would be possible to create a little plugin that reads the DEP/ARR ICAO from the P3D Flightplan and create the ATCAPI config file based on this. @fs1 if that's for interest - let me know.

Sounds like a good idea. And it would bring me back to SimStarter NG which I've not been using since quite some time (p3Dv4.4?).

[fs1 295]

Thanks @Nemo for the feedback. The GUI is just read only, I will be changing it soon. I will liase with @Capt. PERO to integrate this.

Thanks!

[F737MAX 5,608]

On 12/8/2020 at 11:56 AM, fs1 said:

I have updated this new tool to include several airports simultaneously to the config file. Fix log below:

<snip>

Link to download:

https://www.dropbox.com/s/8drsngge4qxml9l/ATCAPI v1.0.0.2.zip?dl=0

I'm using this latest release and it's working well.

My real problem is tyring to use it at EGCC. While other airports appear fine, I still get opposite traffic landing on the same runways as departure. Take-offs from 23L as expected, but most landings on 05R at the same time, which is clearly wrong.

Included the xml code, in case anyone can see if I've made an obvious mistake.

<Airport>

    <ICAO>EGCC</ICAO>
    <ActiveTakeOffRunway>
        <Runway>R23L</Runway>
        <Probability>0.7</Probability>
    </ActiveTakeOffRunway>
    <ActiveTakeOffRunway>
        <Runway>R23R</Runway>
        <Probability>0.0</Probability>
    </ActiveTakeOffRunway>
    <ActiveTakeOffRunway>
        <Runway>R05L</Runway>
        <Probability>0.3</Probability>
    </ActiveTakeOffRunway>
        <ActiveTakeOffRunway>
        <Runway>R05R</Runway>
        <Probability>0.0</Probability>
    </ActiveTakeOffRunway>
    <ActiveLandingRunway>
        <Runway>R05R</Runway>
        <ApproachName>IMC</ApproachName>
        <ApproachType>ILS</ApproachType>
        <Probability>0.3</Probability>
    </ActiveLandingRunway>
        <ActiveLandingRunway>
        <Runway>R05L</Runway>
        <Probability>0.0</Probability>
    </ActiveLandingRunway>
        <ActiveLandingRunway>
        <Runway>R23L</Runway>
        <Probability>0.0</Probability>
    </ActiveLandingRunway>    
    <ActiveLandingRunway>
        <Runway>R23R</Runway>
        <ApproachName>INN</ApproachName>
        <ApproachType>ILS</ApproachType>
        <Probability>0.7</Probability>
    </ActiveLandingRunway>

  Edited December 9, 2020 by F737NG

[Wolkenschreck 269]

You need one configuration depending on your preference/the current wind, i.e. either 23s or 05s. But you can not include 05 and 23 in the same config.

EDIT:
To be a bit more clear here. You see departures on 23L and arrivals on 05R because you assigned both runways at the same time. The tool does not take wind into accounts and will assign traffic based on the probability you have defined. 
    <ActiveTakeOffRunway>
        <Runway>R23L</Runway>
        <Probability>0.7</Probability>
    </ActiveTakeOffRunway>
    <ActiveLandingRunway>
        <Runway>R05R</Runway>
        <ApproachName>IMC</ApproachName>
        <ApproachType>ILS</ApproachType>
        <Probability>0.3</Probability>
    </ActiveLandingRunway>

Edited December 9, 2020 by Wolkenschreck

[Wolkenschreck 269]

Federico,

Might be just bad luck but I do notice a less reliable line up and wait with the new version. Departing traffic lines up once arriving traffic touches down. However, the departing traffic will commence the takeoff roll even with the arriving traffic still decelerating on the runway.

Not sure if this area was touched at all for the new version (maybe with - Optimization of non-blocking algorithm while taxiing. ?) but I just wanted to point it out.

[erj31 0]

1 hour ago, Wolkenschreck said:

Federico,

Might be just bad luck but I do notice a less reliable line up and wait with the new version. Departing traffic lines up once arriving traffic touches down. However, the departing traffic will commence the takeoff roll even with the arriving traffic still decelerating on the runway.

Not sure if this area was touched at all for the new version (maybe with - Optimization of non-blocking algorithm while taxiing. ?) but I just wanted to point it out.

I noticed this as well.  Otherwise, I’m enjoying the app!

[pmemery 4]

same for me as well 

[fs1 295]

2 hours ago, Wolkenschreck said:

Federico,

Might be just bad luck but I do notice a less reliable line up and wait with the new version. Departing traffic lines up once arriving traffic touches down. However, the departing traffic will commence the takeoff roll even with the arriving traffic still decelerating on the runway.

Not sure if this area was touched at all for the new version (maybe with - Optimization of non-blocking algorithm while taxiing. ?) but I just wanted to point it out.

Thanks. Does the roll start prematurely? If so, I can upload a new version of it restoring the previous behaviour.

Edited December 10, 2020 by fs1

[Wolkenschreck 269]

Yes, the roll does start before the arriving traffic has vacated. Sometime departing traffic does wait, sometimes not. 
Meanwhile have I tried the version from Nov 21th and could see the same behavior. So it does not seem to be related to the version. This is my configuration:

    <enableFastTakeOffs>1</EnableFastTakeOffs>
    <allowTakeOffDistance>6000</AllowTakeOffDistance>
    <taxiSpeedLimiter>30</TaxiSpeedLimiter>
    <enableRollthenTakeOff>1</enableRollthenTakeOff>
    <minCrossingRny>2000</minCrossingRny>
    <isGUIVisible>1</isGUIVisible>
    <deployEarlyFlaps>0</deployEarlyFlaps>

But even with the small problem is traffic flowing better than ever with your DLL. The premature take off roll is the only issue I am seeing so far 🙂

[fs1 295]

4 minutes ago, Wolkenschreck said:

Yes, the roll does start before the arriving traffic has vacated. Sometime departing traffic does wait, sometimes not. 
Meanwhile have I tried the version from Nov 21th and could see the same behavior. So it does not seem to be related to the version. This is my configuration:

    <enableFastTakeOffs>1</EnableFastTakeOffs>
    <allowTakeOffDistance>6000</AllowTakeOffDistance>
    <taxiSpeedLimiter>30</TaxiSpeedLimiter>
    <enableRollthenTakeOff>1</enableRollthenTakeOff>
    <minCrossingRny>2000</minCrossingRny>
    <isGUIVisible>1</isGUIVisible>
    <deployEarlyFlaps>0</deployEarlyFlaps>

But even with the small problem is traffic flowing better than ever with your DLL. The premature take off roll is the only issue I am seeing so far 🙂

Ok thanks for the feedback. I can adjust it. When do you suggest the take off roll whould start? I can include an option to tweak it.

[Wolkenschreck 269]

Not sure how your DLL does interact with the sim here. But the roll should start after the arriving traffic has passed one of the hold short nodes that are defined in the AFCAD. I think the status in ATC Explorer changes from landing to taxi in once it has vacated (need to check the exact wording). 

[fs1 295]

8 hours ago, Wolkenschreck said:

Not sure how your DLL does interact with the sim here. But the roll should start after the arriving traffic has passed one of the hold short nodes that are defined in the AFCAD. I think the status in ATC Explorer changes from landing to taxi in once it has vacated (need to check the exact wording). 

Ok I will add this option to trigger the take off AI rollout.

So by doing this, you will have 2 options that will trigger the rollout. A faster option that is current the default one, and then another option at the hold short.

Thanks!

Edited December 11, 2020 by fs1

[him225 51]

Not a good idea as it is highly variable how much time a landed AI will stroll on the runway before vacating depending on the model and taxiway layout, if this takes too long then the lined up AI will cause go around to an incoming landing due to just sitting and not leaving the runway before the landing AI comes near. The current method of triggering a fast rolling takeoff just after landing runway vacation along with the check for minimum distance of incoming landing is more reliable. Better way to make takeoffs clear faster instead and take better advantage of fast rolling takeoff feature would be to force next takeoff clearance as soon as preceding departure lifts off the runway, as currently the AI still wait lined up till preceding departure reaches a certain height causing a delay and greatly limiting the instances where benefit of the fast takeoff ability is possible.

[Wolkenschreck 269]

6 hours ago, him225 said:

The current method of triggering a fast rolling takeoff just after landing runway vacation along with the check for minimum distance of incoming landing is more reliable.

I see your problem and agree that the vacating time is sometimes not optimal. However, the current method initiates the take off roll. while landing traffic is still decelerating with spoilers and reversers deployed. Arriving traffic should be at least attempting to vacate before any takeoff commences. 
Having the tail passed the hold short line would be the most realistic option to define if a landing aircraft has vacated. But maybe could the earliest sign of deviation from the runway heading be used as an earlier trigger to determine if the arriving traffic is about to vacate? Would not be totally realistic but good enough for the sim.

For the takeoff clearance, I found the following in section 3-9-6 Same Runway Separation:
Preceding traffic needs to be airborne and at least 6,000 ft away. 
https://www.faa.gov/air_traffic/publications/atpubs/atc_html/chap3_section_9.html#FIG_3_9_2