Altitude restriction not taken into account by VNAV + Altitude Alert question

[Jojo38000]

Hi, 

 

On a flight from KLAS to KSAN (BOACH6 TNP LINDY4), I noticed that an altidude restriction was missing on the arrival procedure (FL195B at TNP). So I entered it manually (I typed "/19500B" on the scratchpad and entered the restriction on the legs page). This altitude restriction should have moved the TOD by roughly 60 NM, but it didn't. Seems like the whole VNAV path remained unchanged.

I never had this kind of issue before. Even though I had to modify restrictions manually, VNAV has always been quite accurate. Maybe it's because this altitude restriction is before the TOD ?

 

 

On a completely unrelated topic (not even sure it's a bug, and I don't want to start another topic for so little), when is the altitude alert supposed to trigger ? And when it triggers, am I supposed to hear a sound (I noticed an altitude alert sound in the custom sounds folder, so I'm guessing yes ?) ? I've only seen this alert flashing a couple of times, and without any sound. So is this normal, or not ?

 

Thanks for your help, 

Jonathan

IXEG_debug_01.txt

GizmoLog.txt

[Litjan]

Hi Jonathan,

your assumption is correct - for now we disregard any altitude restrictions that are WAY ahead of the T/D - the reason is that it is very hard for us to determine if they should be part of the CLIMB or part of the DESCEND? Maybe we should never climb above FL195 until passing TNP?

We will revisit this problem at a later time - for now just descend to 195 manually in time (you can enter a new CRZ alt of 195 in the Cruise page and do a cruise-descent with 1000fpm).

Jan

PS: Altitude alert will never be heard if the autopilot flies the plane.. You will hear it in manual flight if approaching the MCP alt too fast, or when straying from it for more than 300 feet (iirc)

Edited May 5, 2016 by Litjan

[mmerelles]

3 minutes ago, Litjan said:

Hi Jonathan,

your assumption is correct - for now we disregard any altitude restrictions that are WAY ahead of the T/D - the reason is that it is very hard for us to determine if they should be part of the CLIMB or part of the DESCEND? Maybe we should never climb above FL195 until passing TNP?

We will revisit this problem at a later time - for now just descend to 195 manually in time (you can enter a new CRZ alt of 195 in the Cruise page and do a cruise-descent with 1000fpm).

Jan

 

I do understand your point for a random waypoint enroute.

But TNP (twenty nine palms) is part of the LYNDY4 arrival, i think the FMC should at least recognize whether the pilot is entering/changing/removing a restriction that belongs to the STAR procedure -or the SID- is safe to asume is part of the DESCEND -or the CLIMB- and the FMC should make the necessary computations to comply.

https://skyvector.com/files/tpp/1605/pdf/00373LYNDI.PDF

[Jojo38000]

Thanks for this super-quick answer. 

Indeed, descending manually and re-catching the VNAV path at a later time worked flawlessly, as expected.

Regarding the altitude alert, I'm assuming from your answer that the lights and sounds are "independant". So a flashing light does not necessarily mean that the sound should trigger as well ? The light can trigger when the autopilot is engaged (I think I saw it when using FL CH), but the sound will only when manually flying the plane.

Sorry to be so "picky" about that, but I've had a quite frustrating bug regarding the altitude alert sound in the flyjsim 732, so I've become quite paranoïd on this very specific point. 

[Litjan]

I´d have to think hard about it to get the behaviour of the altitude alert right off of the top of my head - maybe someone can post the snippet from the real FCOM?

You might be suffering from the "can´t hear certain sounds" syndrome, though - usually attributed to conflicting plug-ins. I THINK you should at least hear the C-chord sound once when triggering the alert, after that the light keeps blinking without sound.

I agree about the LYNDY4 arrival, but this is a different problem. Jojo reported that the restriction wasn´t imported correctly and he added it manually.

We will look into why the restriction wasn´t imported initially (had some other reports about that, too)

Jan

 

[Shifty]

Jojo,

Different 300's have different options for the alert horn, some of ours at Jet2 give you the horn all the time when approaching the altitude even with the autopilot in and any mode. Some will only give you the horn if you deviate 300ft or more from your MCP level. The deviating one is important as it's an RVSM requirement. Examples below of 3 different type of aircraft options. 

Shifty 

 

Edited May 5, 2016 by Shifty

[Jojo38000]

Hi shifty,

Thanks for those informations, much appreciated.

 

So I've tried with all plugins removed (except gizmo, obvioulsy) and I can hear the sound. Well, hear is actually a big word as the sound is so weak I had to turn off the packs and put on my headsets to actually hear it. And even in those conditions, I really had to listen closely. It kind of destroys the purpose of an alert, doesn't it ? 

I will try reintroducing my plugins one after another to see if it was indeed a plugin problem. Maybe the sound was working correclty since the beginning. 

I personnaly think that the sounds need some reajustments, maybe the packs and the wind are too loud compared to the rest ? I tried to stall the aircraft in order to see how loud that alert was as well, and it was kind of weak too (although way louder than the altitude alert imho).

 

Edited May 5, 2016 by Jojo38000

[mmerelles]

1 minute ago, Jojo38000 said:

Hi shifty,

Thanks for those informations, much appreciated.

 

So I've tried with all plugins removed (except gizmo, obvioulsy) and I can hear the sound. Well, hear is actually a big word as the sound is so weak I had to turn off the packs and put on my headsets to actually hear it. And even in those conditions, I really had to listen closely. It kind of destroys the purpose of an alert, doesn't it ? 

I will try reintroducing my plugins one after another to see if it was indeed a plugin problem. Maybe the sound was working correclty since the beginning. 

I personnaly think that the sounds need some reajustments, maybe the packs and the wind are too loud compared to the rest ? I tried to stall the aircraft in order to see how loud that alert was as well, and it was kind of weak too (although way louder than the altitude alert imho).

 

you can tune the packs volume on the aircraft menu

[Jojo38000]

Oh, didn't see that one. My bad. Thanks !

 

edit : I tried ti tune it to better hear some of the sounds, but I still find the altitude alert to be very weak. Anyway, that's just details, but I wouldn't mind it being a bit louder though. Thanks all for the help.

 

edit 2 : Yep, in the end it was working fine since the beginning. Well at least that's one more bug solved (even if it's an imaginary one).

Edited May 5, 2016 by Jojo38000

[Litjan]

I upped all warning sounds a bit with the next update...

Jan

 

[tkyler]

6 hours ago, mmerelles said:

But TNP (twenty nine palms) is part of the LYNDY4 arrival, i think the FMC should at least recognize whether the pilot is entering/changing/removing a restriction that belongs to the STAR procedure -or the SID- is safe to asume is part of the DESCEND -or the CLIMB- and the FMC should make the necessary computations to comply.

Yes, but TNP is part of BOTH the SID transition and the STAR transition....so when these are entered, the FMS has to make a determination..."which one do I keep"?  

No we have a set of rules for these cases.... but they are 'growing' as we see new situations and this is a new one.  In this particular case, TNP associated with the STAR has a restriction, whereas TNP associated with BOACH does not have any restrictions.....and so I'd think the one with the 'restriction' wins....and I will now add this to our "rules" when we encounter duplicate points.  

Now if BOTH had a restriction, that could get complicated.  In such a  case, we'd have to look for another rule to apply ...and things get a bit more sticky here in that we may generalize some rule that works for situation A, but not situation B.   What happened here is my code chose TNP associated with the SID (with no restriction) when it should have chosen TNP associated wiht the STAR (because the restriction supercedes).  This is on my todo list now.

-tkyler

[mmerelles]

5 hours ago, tkyler said:

Yes, but TNP is part of BOTH the SID transition and the STAR transition....so when these are entered, the FMS has to make a determination..."which one do I keep"?  

No we have a set of rules for these cases.... but they are 'growing' as we see new situations and this is a new one.  In this particular case, TNP associated with the STAR has a restriction, whereas TNP associated with BOACH does not have any restrictions.....and so I'd think the one with the 'restriction' wins....and I will now add this to our "rules" when we encounter duplicate points.  

Now if BOTH had a restriction, that could get complicated.  In such a  case, we'd have to look for another rule to apply ...and things get a bit more sticky here in that we may generalize some rule that works for situation A, but not situation B.   What happened here is my code chose TNP associated with the SID (with no restriction) when it should have chosen TNP associated wiht the STAR (because the restriction supercedes).  This is on my todo list now.

-tkyler

Interesting situation...

I have seen this scenario dozen of routes in PE over the SoCal area, because all flights departing KLAS and arriving to the WEST (KSNA, KSAN, KLAX etc) share the same transition point for the SID and the STAR such us TNP, HEC among others, also flying back to KLAS you share DAG for SID/STAR quite often.

Being a PE member, i also see there are 733's online at all times, so this scenario comes into play quite often. I also seen none of the SIDs has restrictions for shared transitions while some STARs have restrictions for entering the transition.

 

If this helps... this is the way i look at it when SID/STAR share transition over a short route:

-If only one has restriction, that one should take precedence

-If none has restriction and the user didn't entered anything, then you go to cruise from your last sid restriction, then you descend to comply first star restriction.

-If none has restriction but the user entered something i think its safe to asume this is part of the descend profile and t/d should be recalculated, because the SID transition occurs at the end of the departure procedure and rarely will require restriction? while ATC quite often ask you for an altitude entering the procedure

Edited May 6, 2016 by mmerelles

[Jojo38000]

You've probably thought this through many times, but wouldn't a distance based rule help you determine if a restriction is part of the climb or the descent ?

If the waypoint is closer to the calculated TOC than to the TOD, then it's a climb restriction, otherwise it's a descent one ?

That could possibly help when you enter manually such a restriction (i.e. when you already have a vnav path). But not sure this helps in the Sid/Star situation, unless you can detect borderline cases (easier said than done), calculate a vnav path without those borderlines cases, and then use this distance rule. But that wouldn't be very good performance wise. 

 

Anyway, thanks for taking the time to share and explain the details of how you FMC is working, very interesting indeed.

 

Jonathan

[tkyler]

Thanks guys.  We have come across just about everything and as mentioned, what works in one set of situations, tend to break down in other siuations in other parts of the world where procedures tend to have different 'patterns'.  This is why someone who flies regularly in one part of world thinks the FMS is 'great' whilst someone who choses a part of the world where the procedures are a bit more...um...challenging, see the FMS as buggy.   Writing rules to make the FMS smart in all these cases....while not completely the 'bane of my existence', certainly presents challenges...especially since my ability to fly "routes all over the world" would take me some number of months indeed.

9 hours ago, mmerelles said:

i think its safe to asume this is part of the descend profile and t/d should be recalculated

Boy would I love to believe that....but Jan has proved me (and himself) wrong on a few occasions with our assumptions.  With over 300,000 nav points in the database, the combination of what you might encounter is tough to predict sometimes...I am amazed at the combinations I see sometimes.   I am firmly of the opinion that evaluating these on case by case and expanding and adding to, the "rules" relative to other rules is the best course....though we clearly have to wait until they are encountered to evaluate them properly.

-tkyler

Edited May 6, 2016 by tkyler

[avantime]

Sorry to awake an old thread but is it possible to have (or perhaps mod) an always-active altitude alert, similar to what Shifty described? I flew a lot of payware aircraft and find it most unusual to not have any form of altitude alert (chime and/or light) when autopilot is in command.

[Jojo38000]

Hi again, 

 

Since the 3rd hotfix I can't hear the alt alert at all. I have the 2500ft-and-minimum-missing-callouts bug as well, so maybe related. Just wanted to let you know so you could have a look.

I'm unfortunately away from my home computer, so I won't be able to do any troubleshooting.

 

I'd love to have an alerts sounds slider as well, if possible. Just my 2 cents.

 

[Litjan]

I noted the request for a modified altitude alerter function.

We have a few sound-fixes in for the next hotfix, please report back after that one?

Thanks, Jan

 

[Jojo38000]

The missing callouts are back and work as expected.

But no luck with altitude alert, the sound still appears to be missing. I can hear all the other alarm sounds (stall, overspeed) very distinctly, but the altitude alert never sounds. 

I flew the plane with AP off, AT on, and the altitude alert light did light up.

[Litjan]

2 hours ago, Jojo38000 said:

The missing callouts are back and work as expected.

But no luck with altitude alert, the sound still appears to be missing. I can hear all the other alarm sounds (stall, overspeed) very distinctly, but the altitude alert never sounds. 

I flew the plane with AP off, AT on, and the altitude alert light did light up.

Hi Jojo,

at least a step in the right direction... it´s a shot into the wild, but can you try to close as many other programs possibly using sounds (like browsers, youtube, SoundMaxx, etc) and try again?

Also try this: Fly at 5000 feet, set the MCP ALT to 5000 feet. Now climb to 6000 feet (leave the MCP ALT at 5000!). Do you get the sound now?

Thanks, Jan

 

[Jojo38000]

Tried with all other programs closed, did what you instructed, and no luck. I get the flashing light when leaving the altitude manually flying, but no sound to be heard. 

I didn't change anything on my x plane (no new plugin, etc...) since hotfix 2, which is the last time I was able to hear the alert. I'm running on windows, don't know if this could play any role in the problem.

 

Hope this helps

Edited May 22, 2016 by Jojo38000

[Litjan]

Ok - can you find out what your soundchip properties are? We are trying to see if there is a pattern to the soundreports we get.

Thanks, Jan

 

[Jojo38000]

Away from home for the whole week, so I can't give you much detail right now. 

It's a realtek audio card, I will give you the specifics as soon as I can.

[Litjan]

2 hours ago, Jojo38000 said:

Away from home for the whole week, so I can't give you much detail right now. 

It's a realtek audio card, I will give you the specifics as soon as I can.

Thanks a lot, Jojo!

[Jojo38000]

Hi again,

Here are the details I could find regaring my sound card :

 

 

Hope this helps, and please let me know if you need anything else (but before the weekend ends, otherwise I'll be gone again :P)

 

Jonathan