Unable to select SID transition

[Sarun Intaralawan 0]

I've just bought a PMDG 737 NGX, and I am doing a test flight from VTBD. It seems that I can't select SID transition, instead, the CDU gives me the message "ALT CONSTRAINT FRANK" as I'm trying to select BEKOD transition (FRANK is a name of a waypoint, see the picture below). I'm using Navigraph Navigation Data cycle 1504 revision 1. Any ideas on this issue?

 

Regards,

Sarun Intaralawan

 

[dave_paige 11]

This sounds similar to a problem I've always had with the POM7 departure out of KONT in the States. When ever I select the DAG transition it get an error message "ALT CONSTRAINT at POM". What is strange is that there IS an altitude constraint of 7000ft at POM so the I don't understand the need for the announcement. In any case, the next two waypoints fail to get inserted, SULZU and FROUN and I have to had them manually. I've looked at the coding for the SID in the data base and can't find anything that looks wrong.

 

Maybe Dan Downs can have a look and way in on what might be happening here.

 

Dave

[Sarun Intaralawan 0]

Yes, same for me. The waypoints fills up to FRANK, but 3 points after that don't.

 

Edit: FRANK also has 7000 ft or below restriction

 

Sarun

[downscc 1,327]

Yes, same for me. The waypoints fills up to FRANK, but 3 points after that don't.

 

Edit: FRANK also has 7000 ft or below restriction

 

Sarun

I can fix this but I would like you to do something in return.  Please post a bug report at the Navigraph forum. Thank you.

 

The fix:  The problem is the last fix in the SID without transition has an altitude constraint of AT OR BELOW 7000 and the first fix in the transition has an altitude constraint of AT OR BELOW 16000 AT OR ABOVE 7000 which is silly because the fix is 24 nm away.  Open the VTBD.txt file with a text editor such as note pad, find the SID ("SID FRANK2 FIX BD011 FIX BD021 AT OR BELOW 6000 FIX FRANK AT OR BELOW 7000") and the lines that follow are the runway constraints and then the transitions. Delete "AT OR ABOVE 7000" from the transitions. For example, "TRANSITION BEKOD FIX BD025 AT OR BELOW 16000 FIX BD026 FIX BEKOD"

 

You may copy and paste the above paragraph in your Navigraph forum post. Okay to mention my name too (Dan Downs), Stefan and I have worked together.  By notifying Navigraph, the solution will be in future cycles and you will not need to manually edit the procedure.

 

Not sure what's going on at KONT, maybe something along the same lines since Stefan's translation program is used for global sidstars.

 

 

This sounds similar to a problem I've always had with the POM7 departure out of KONT

 

I looked at KONT sidstar and agree, it looks okay but if you delete the AT OR BELOW 7000 constraint at FIX ONT it will add the transitions.  I don't think that's right and will mention it through my beta channel.

 

EDIT:  You can delete either the AT OR BELOW in the SID last fix or the AT OR ABOVE for the first fix in the transition. Either works, neither should be required but is for now.

[scandinavian13 5,192]

 

 

I can fix this but I would like you to do something in return.  Please post a bug report at the Navigraph forum. Thank you.

 

Thanks for doing what you do, Dan!

[Sarun Intaralawan 0]

I do look up VTBD Charts, and it says exactly what the navdata says (see picture). Interestingly, this procedure is from 2001, so it is a 14-year-old procedure.

 

Sarun

 

PS. will post to Navigraph forum soon

 

[NAVData 24]

Hi guys,

Sarun pointed me to this topic in our forum. I have tried to figure out what the issue is, but I´m not sure, if the solution from you Dave is really a solution. The reason is, that in nearly all transitions are "between" altitude restriction - crazy, unlogic, silly, ... whatever you want but there are these restrictions. I have looked on to the current charts too and again, you see these restrictions.

 

The "solution" is now: to supress all "between" restrictions, which means in all procedures but that can´t really be the solution because sometimes it makes sense, sometimes possible not. Further when you look onto the charts, you see, that there is a Military flying area around Don Mueang, possible that this is the reason for this special restrictions ...

 

So, the question is:

Should we really remove the "between" constraints ... ???

 

By the way, in the PMDG 777, there is no "constraint issue" with exactly the same syntax ... the PMDG 777 uses exactly the same procedure-file as the 737NGX -

 

Here are the current chart of VTBD SID Rwy 21L/R Frank2

[Sarun Intaralawan 0]

Hi Stephen,

 

Since I don't own the 777X, I do not have a chance to test that. But thanks to point out that it works fine in the 777X.

 

So, what I can do now is wait for the patch of the 737NGX, right?

 

Sarun

[ubersu 78]

Oddly enough, if you add BEKOD manually and enter the 160B070A constraint it gets properly added without issues so you really don't have to wait for a patch if you want to fly it.

 

DJ 

[dave_paige 11]

Stefan,

 

It wasn't me who suggested removing any restrictions. I said the work around I suggested was to re-add the waypoints that get left out and then re-enter the restrictions. And, for now, that's what I do. I believe it was Dan who said that removing either the restriction at the end of the core part of the SID or the restriction at the beginning of the TRANSITION part of the SID would correct the error in the FMC and the further waypoints would not be left out. I also assume DAN would then contend that you should put the restriction back in in the CDU.

 

I don't believe this is an issue with the NAVDATA. It seems more like an issue in the PMDG FMC coding. It seems the FMC has a problem with SIDS that have an altitude restriction at the end of the core portion of a SID and then another altitude restriction right at the beginning of the TRANSITION portion of the SID. But that's just my guess.

 

BTW I'm only referring to the KONT POM7 departure as that's where I discovered this problem.

 

Dave

[downscc 1,327]

I've submitted the problem to PMDG.  I wouldn't look for a fix until NGXv2 though.  Meanwhile, do what is best for you.

[dave_paige 11]

Thanks Dan,

 

Glad to hear PMDG are looking into it. To bad we'll have to wait until v2 but the work around is not really a big deal.

 

Dave