Database error report: Flying the P3D5.3HF2 MilViz B350i, using Navdata
{“cycle”:“2212”,“revision”:“1”,“name”:“MilViz King Air 350i”}
Discovered that though GEG VOR is correctly located, when I load the KCOE ILS R06 and select the GEG transition, the GEG waypoint suddenly moves several miles southeast, messing up the approach. Guessing that for the KCOE ILS R06 GEG transition as coded for this airplane, the GEG is being reloaded, and the database for the transition is wrong. Selecting the VECTOR transition leaves GEG in the correct location. Problem apparently unique to his transition - never encountered similar elsewhere in 3 years flying the MV airplane.
Chuck O
Hi Chuck,
I have checked the database and all seems ok - the legs in the terminal procedures (SIDs, STARs and IAPS + all kind of transitions) has no coordinates included, only references to the navaids/waypoints. So in other words, when the navaid or the waypoint is located correctly, the terminal procedure uses exactly this location. It could be, that some waypoints will be calculated (depending on the leg-path type) like the GEG transition for the ILS 06.
The first leg path on the ILS06 GEG transition is a FC (= track from a fix for distance), which means, it will only calculated correctly when you are in the air and flying - therefore you will see this calculated point not correctly on your ND.
Against the RNAV06 GEG transition, here the first leg is a IF (= initial fix) and this fix is the GEG VOR, which means a clear point and the procedure can be shown correctly, without any additional parameter like the coding before.
I´m pretty sure, when you fly the R06 GEG transition, you will see that this first calculated waypoint will also be shown correctly. This is normally only a viewing issue on your ND due the calculation and the “missing parameter” which are not available on the ground.
Again, I haven´t seen any navdata issue here - so, I´m sure it´s only an issue with drawing the flight path on the ND.
Hope that helps,
Richard
I understand the issue is not with the data, but I must say I don’t understand your explanation Richard.
The initial leg for the ILS is indeed FC, but such a leg starts at a “fix” (here, the GEG VOR), so I don’t see what information is missing and/or what ambiguity exists that requires being airborne for the leg (or at least, its starting point) to be drawn correctly? Were you thinking of a CD leg perhaps?
Regards,
Tim
Thanks Richard. When I flew it on Pilot Edge earlier this week, passing HUNIB northbound on V253, I was talking to KGEG approach, and hadn’t noticed the fact that my selecting the KCOE ILS R06 GEG had moved GEG about ten miles southeast. After HUNIB, the autopilot turned me eastward toward the newly improperly located GEG. GEG approach alerted me I was turning off route. So I think the autopilot was flying the same route as displayed on my ND. It wasn’t that the autopilot had dropped GEG and was taking me direct to the IF YUCSU. Instead I found myself flying a HUNIB - fakeGEG-YUCSU dogleg. But to be cerrtain I’ll go refly it again and make sure the autopilot wasn’t taking me to the correct GEG, but the ND was showing a dogleg.
Will also try flying a similar approach elsewhere, the KCLM (Fairchild) ILS R08 TOU transition, arriving northbound from OZETT to TOU (IAF). When I pass OZETT, does TOU move southeast so I wind up flying and OZETT - fakeTOU- YUCSU dogleg?
Chuck
Richard - Could it be that the KCOE ILS06 GEG should have GEG as an IF type?
I put the MV B350i on the ground at KPUW, programmed the route, and the moment I selected GEG as a transition, GEG moved to an erroneous position, as shown in this screenshot. Note I wasn’t in the air. When I eventually was, the FMS flew the displayed route - till my PE approach controller caught it.
The RNAV06 GEG loaded correctly.
To chase this further, I moved to KUIL, and set up a route for KUIL-KCLM to fly the KCLM ILS08 from TOU, since it has similar geometry to the KCOE RO6 ILS, here with the TOU VOR as an IAF. When I selected the TOU transition, the approach loaded correctly, as shown in this second screenshot:
If you compare the way the GEG and TOU transitions are coded, is there any difference that could explain the problem at GEG?
Regards
Chuck O
Richard already explained the difference in coding between the transitions for the ILS and RNAV at GEG. But the issue here is the Milviz’s parsing/use of said data, not the data itself.
Regards,
Tim
Agree, but the difference between the TOU and GEG transition type coding to their respective ILSes may nonetheless provide a useful clue.
Chuck
The TOU transition into KCLM is coded in the same way as the RNAV06 GEG transition, as IF.
I´m still be sure, that this is a calculation error in the FMC. An IF leg path is a single waypoint, no calculation required but the FC leg path needs a waypoint, a direction and a distance - it´s like a “place to bearing waypoint” and this kind of waypoint must be calculated.
Cheers,
Richard
Thanks Richard. Not sure I understand why the KCOE and KCLM VOR transitions were both coded as IF’s, whereas the GEG transition for the KCLM had to be coded as an FC. But the difference may account for what I saw.
Meanwhile discovered that if I put the KCOE destination airport after GEG at the end of the main route, and then select the approach and transition, the whole approach and transition gets stringed afterwards, so the GEG transition fix appears twice, before and after KCOE. So this way all the waypoints load properly. And it works like a Garmin - FMS flies you toward KCOE till you are cleared and you do a direct to the approach transition fix GEG. Nothing mentioned in the Collins manual about need to terminate main route with destination airport - so it all must result from a logic bug in the MV B350 FMS simulation.
Many thanks for all the help in understanding this!
Regards
Chuck
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.