Jump to content

Dealing with skipped waypoints and adding arrivals


Berzerker

Recommended Posts

Would it be possible to add in some logic on the backend that handles situations where if you forget to set a DIR after being given one, it never updates your flight plan once you reach subsequent waypoints?

 

Also, when adding in an arrival, or updating an arrival, it always seems to set your Active WPT to the first WPT in the arrival/approach, it would be good if there was some logic to recognize which one you're inbound to or near, or perhaps to update it once you pass over the next one to know which your Active WPT truly is.

 

Thanks.

Link to comment
Share on other sites

46 minutes ago, Berzerker said:

Would it be possible to add in some logic on the backend that handles situations where if you forget to set a DIR after being given one, it never updates your flight plan once you reach subsequent waypoints?

If you forget it, how shall the software know about it? I guess that this is not possible.

 

46 minutes ago, Berzerker said:

Also, when adding in an arrival, or updating an arrival, it always seems to set your Active WPT to the first WPT in the arrival/approach, it would be good if there was some logic to recognize which one you're inbound to or near, or perhaps to update it once you pass over the next one to know which your Active WPT truly is.

Why not just use the DIR-TO function in such a situation? If programmable at all, such a logic would be far too error prone.

Link to comment
Share on other sites

On 8/22/2023 at 3:08 PM, aivlasoft said:

If you forget it, how shall the software know about it? I guess that this is not possible.

 

I assumed by saying "add in some logic" that meant trying to come up with some way to do it. Obviously if you're nowhere near another WPT then it's probably impossible, but perhaps reading a track and assuming that direct to that track for 5+ or 10+ minutes means you're DIR to that WPT and it automatically updates. Likewise perhaps when overflying another WPT, it can automatically update.

 

On 8/22/2023 at 3:08 PM, aivlasoft said:

Why not just use the DIR-TO function in such a situation? If programmable at all, such a logic would be far too error prone.

At the very least, when updating an arrival or adding an approach, it should not restart you back at the beginning. It should at the very least keep you DIR TO the same waypoint you were before.

 

As for adding an arrival after you've been on a vector or something, for ex, the DIR TO can be automatically applied once flying over a WPT next time (within, say, 2 or 3nm if not an overfly waypoint).

 

Just trying to throw out some ideas.

Link to comment
Share on other sites

1 hour ago, Berzerker said:

Just trying to throw out some ideas.

That's fine, thanks.

 

Just a few thoughts from my side as the programmer. To implement a logic in a program one requires that clear and unambiguous rules are available, which this logic must then strictly follow. I think that there are a lot of different possibilities in the situations described above, so that it is almost impossible to identify all cases and to determine an appropriate set of rules from them.

 

Not always every situation can be solved with a program (at least not with reasonable effort), therefore the DIR-TO function was implemented, which allows the pilot to make its decisions based on his experience and the situational awareness and then to act accordingly.

 

Link to comment
Share on other sites

I can potentially see how analyzing tracks and time and all that can lead to some ambiguity, but I think at least the two things I mentioned in my previous comment are pretty clear-cut when it comes to what's going on:

 

1) If you pass directly over a WPT or at least within a few NM (1-2nm), it's clear you were DIR that WPT and it should auto update

 

2) Inputting an approach after already being on the arrival/having input the arrival should put you back on the previous DIR WPT you were on before you input, not back to the beginning.

 

Let me know your thoughts.

Link to comment
Share on other sites

2 hours ago, Berzerker said:

If you pass directly over a WPT or at least within a few NM (1-2nm), it's clear you were DIR that WPT and it should auto update

This is the logic which is implemented already. A WPT is considered as passed if you fly over or by within a range of 3 NM. However, the condition is that all waypoints before must also be passed.

2 hours ago, Berzerker said:

Inputting an approach after already being on the arrival/having input the arrival should put you back on the previous DIR WPT you were on before you input, not back to the beginning.

Changing an arrival and/or an approach when you already are on this arrival or approach will always cancel the above mentioned logic because changing an arrival and/or an approach will change/remove multiple waypoints in the flight plan and therefore the logic must be manually reset. If you change your flight plan you always have to use the DIR-TO function to re-sync the logic with your current flight plan. There is no other way to accomplish this.

Link to comment
Share on other sites

On 8/26/2023 at 3:45 PM, aivlasoft said:

This is the logic which is implemented already. A WPT is considered as passed if you fly over or by within a range of 3 NM. However, the condition is that all waypoints before must also be passed.

That's my point, I think it should not have that requirement. If you pass directly (or within 3nm) of a waypoint, it should update no matter what you've passed before. I can't think of a situation where when you're passing within 2-3nm of a waypoint means that's not your current DIR and it shouldn't update.

 

On 8/26/2023 at 3:45 PM, aivlasoft said:

There is no other way to accomplish this.

I think it should be possible to store the current DIR-TO waypoint in "preparation" for an update or approach change. Just have an always updating "currentDIRWPT" variable, something like that.

 

i.e. I'm direct WW984, but I need to change the approach, but WW984 exists on the new input, it should match that and automatically run a "DIR WW984" update.

Link to comment
Share on other sites

13 minutes ago, Berzerker said:

That's my point, I think it should not have that requirement. If you pass directly (or within 3nm) of a waypoint, it should update no matter what you've passed before. I can't think of a situation where when you're passing within 2-3nm of a waypoint means that's not your current DIR and it shouldn't update.

Especially on certain (RNAV-) approaches this will not work because the waypoints are too close to each other. That's the reason why the requirement was implemented that all waypoints before must be passed. Otherwise the sequence might get a hick-up.

Link to comment
Share on other sites

On 8/28/2023 at 2:42 PM, aivlasoft said:

Especially on certain (RNAV-) approaches this will not work because the waypoints are too close to each other. That's the reason why the requirement was implemented that all waypoints before must be passed. Otherwise the sequence might get a hick-up.

Wouldn't just using the closest waypoint alleviate this issue? even if you have to down to a matter of tens or hundreths of a nm.

Link to comment
Share on other sites

Have a look at these screenshots.

 

1) KCLM ILS08 via JIGEB:

This is a good example for so many approaches, especially in the US where you fly over a VOR or a fix, then outbound to another fix where you make a procedure turn and then fly back the same way again.  Here you have to pass the waypoints in the red circles twice. If the 'logic' were taking just the closest waypoint, then all the waypoints after ELWHA were being considered as passed as soon as you pass ELWHA for the first time.

 

KCLM ILS08 JIGEB.png

 

Another example where taking only the closest waypoint could lead to unwanted effects. Approach EDDS ILS25 via REU25: While on the northeast leg (068°) passing IBIRU, or later at DS522, the waypoints on the 'other side' are too close to get activated, especially when you don't fly accurate enough on the desired track.

EDDS REU25.png

 

From my point of view there is no reason to change the currently implemented logic. It works for a vast majority of situations, and for all not covered cases just use the DIR-TO function to sync the flight plan.

 

 

Link to comment
Share on other sites

Well that's why I was saying that it needs to be precise. When you're DIR-TO a waypoint, you're within 1 or even less than 1 NM of passing through or around the waypoint. That should be more than enough distance to recognize that you were or are DIR-TO that point and can update.

 

I can see how passing over a waypoint twice might be a potential issue, but that should theoretically solve itself since if your flight plan is followed properly, the sequence should still play out how it would normally.

 

i.e. you are direct those waypoints, then hold back into the approach, it should be ordered correctly in the flight plan that it will go ELHWA OCUVI HUTUL YUCSU then HUTUL OCUVI ELHWA. I don't think you'd get close enough to another waypoint before passing over one for it to update.

 

As well, I think the logic to auto-update should only be applied if you are passing over a waypoint that's *not* the next one. As long as you don't get within 1nm of another waypoint, there's no reason to bypass any of the routing. However, if you are approaching a waypoint within 1nm that's 3, 4 or 5 waypoints ahead, it should update.

 

  

On 8/30/2023 at 9:40 AM, aivlasoft said:

It works for a vast majority of situations, and for all not covered cases just use the DIR-TO function to sync the flight plan.

 

Well that's why I ended up making this post because I disagree. I find myself very often having to use DIR-TO because of approach reconfigurations or assignments. It's quite annoying to have to DIR-TO every time my runway changes or I have to put a transition or approach in after not being assigned one while on the arrival. And in most of those situations, I am using DIR-TO to the same waypoint I was DIR-TO previously.

Link to comment
Share on other sites

  • 2 weeks later...

@Berzerker Do you have any problems using the "DIR-TO" function? Do you use it that often?
It's no problem to use the DIR-TO function. It's a quick and easy way to react to unforeseen situations   🙂
I don't really understand your insistence on unnecessarily complicating the programming of this software  😮

Link to comment
Share on other sites

On 9/14/2023 at 10:03 AM, GoofyJP said:

@Berzerker Do you have any problems using the "DIR-TO" function? Do you use it that often?
It's no problem to use the DIR-TO function. It's a quick and easy way to react to unforeseen situations   🙂
I don't really understand your insistence on unnecessarily complicating the programming of this software  😮

I've already given all the reasons of why I use it often and it's annoying to have to use it so often. You've clearly did not read the thread. I guess it's not annoying to you, and you don't have to understand it. But it's annoying to me, and I've clearly laid out why.

Edit: I've just had to use it again, just for an example. I was on the BALSI1D into LFML, I loaded in the approach/runway, and nearing DOLIV, I was told to expect the approach "via DOLIV", well now I have to go back in and select the DOLIV transition, which, of course, reset my plan back to the beginning of the arrival, then I had to select DIR DOLIV again. It could have recognized that I was inbound DOLIV and attempted to reassign it manually.

 

I'm not saying there's a perfect solution, but I think it could be great improved as it stands now.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...