PRFUM SID coding for KLN900 varies compared to GNS530

GNS430 version:
IF,ROPPR,35.971186,-115.301664, ,0.0,0.0,3,7000,0,0,0,0,0,0
TF,CEASR,35.866400,-115.261914,0, ,0.0,0.0,0.0,0.0,2,8000,0,0,0,0,0,0
TF,HITME,35.821389,-115.074167,0, ,0.0,0.0,0.0,0.0,2,11000,0,0,0,0,0,0
TF,WINDS,35.856486,-114.598836,0, ,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,0
TF,KADDY,35.742406,-114.383531,0, ,0.0,0.0,0.0,0.0,2,20000,0,0,0,0,0,0
TF,PRFUM,35.506794,-113.943014,0, ,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,0

Note that it ends at PRFUM, per the title of the chart (PRFUM4.PRFUM).

However, the KLN900 version is encoded as:

Note that it ends at KADDY.

The KLN900 DB has PRFUM as being part of the DRK transition, as follows:

Is that because it requires at least two waypoints in the transition definition or something along those lines?

Hi Keith,
no, according the ARINC424 specification, a terminal procedure must have at least one record so the logic is more >=1 … the GNS430 is the more correct one because here you see the connection-waypoints (as you have identified - means the last waypoint of an runway-transition is the first of the common-part and the last common-part waypoint is the first of the enroute-transition. That means, the GNS430 can handle these “double” connection waypoints internally but most addons/FMCs can´t handle this and you have either double waypoints or a sometimes a “discontinue” (depending of the addon).

Therefore, we removed normally the last (or sometimes the first) waypoint - this is depending on the combinations (runway-trans - common - enroute-trans or viceversa for STARs). This is more or less a complex way but the only one to make such procedures possible in some addons.

you see this in the KLN900 against the GNS430 also:
The KLN900 doesn´t support runway-transition as the GNS430 - it´s a part of the common part here and when you look on an example like 19L in the GNS430 the runway-transition for 19L ends at ROPPR and the common part starts at ROPPR. In the KLN900 we had no separate runway transition, it´s merged into the common part and when we would use the same logic as in the GNS430, we had ROPPR twice … therefore, we removed on of them.

Sorry, little bit technical but necessary to understand … :wink:

I had a feeling it was a limitation of the KLN900 that was causing the different encoding. Thank you for the detailed, prompt reply. That’s all I can ask for.

1 Like

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.