Narrative:

I was flying pilot on this leg. While flying the BRDJE1 arrival into dfw between waypoints stonz and rockz approach control indicated that we began our descent from 11000; the stonz crossing altitude; for 8000 feet; the rockz crossing altitude prior to reaching stonz. She provided a phone number to call to discuss the 'deviation' upon arrival. The phone discussion revealed that there have been many of these supposed deviations with these new arrivals and of course everyone is trying to figure out why.during the entire arrival I determined my proper altitude as related to each fix and when I could begin further decent by the act of the fix disappearing from the map display. When the fix disappeared; I had crossed the fix. When the stonz fix disappeared as the gfms cycled to the next waypoint I began descent to 8000 feet.I would like to discuss generically what I think is a general issue with these arrivals and then discuss more specifically our situation.having given the situation some thought I think what is occurring is that because stonz is not a fly over fix the gfms is computing a turn that begins before stonz to establish the track to rockz. When it begins this turn the stonz waypoint disappears as the gfms cycles to the next waypoint. The stonz waypoint is disappearing from the map indicating fix passage before actually reaching the fix. This cues pilots that descent is allowed to next altitude. Depending on how the gfms computes when to start this turn the stonz fix could disappear earlier or later than standard so as to join the track to rockz. There is no other way to know when you actually are past stonz since the distance to waypoint is now showing info for rockz. Apparently this is happening a lot with manual descents not having or using vnav capability. If one happens to see the distance to waypoint figure at the instant before cycling to the next waypoint a guess could be made as to when that waypoint would be passed. This would still just be a guess and not good enough. Because of the way these arrivals are constructed and with the variations in ATC constraints given for heading; speeds and 'direct to' clearances; pilots are becoming spring loaded to get on with descents as soon as possible. When the gfms cycles to the next fix we really want to go down so as not to miss a crossing. I have needed to use spoilers more in the last couple of months than in the previous 20 years of MD80 flying. We need in the MD80 a way to know when we are actually past the fix when it starts the turn prior to the fix. Alternatively; these fixes need to be fly over fixes so that we will always know our distance to waypoint.in our particular situation I believe that an equipment malfunction could have contributed to an early descent. Enroute we noted that there was no wind arrow displayed on the navigation display. Looking at the progress page on the gfms it showed an erroneous wind speed of between 700 and 850 knots. I believed that the gfms excluded this information as unreasonable and was the reason why the wind arrow was not displayed. The position of the aircraft was crossed checked with VOR information and was completely accurate. The progress page did show a groundspeed figure as computed from the GPS. This ground speed was correct when compared to the flight plan groundspeed figure and our calculated groundspeed. I could not locate a QRH procedure for this situation. We had no gfms messages or map flags or messages. I believed the gfms position to be accurate and the groundspeed indicated to be correct.believing that the gfms knew where it was going and how fast it was going and absent any QRH procedure directing not to use RNAV procedures I didn't feel that we had a degradation in navigation capability to declare. I can find no reference in our manuals about how the gfms actually determines when to start a turn. I presumed that it is based on our groundspeed. If it indeed takes into account the calculated winds then that would cause it to calculate a turn at the wrong distance if using that bad wind calculation data. This could have caused an early turn for us and the cycling of the waypoints early in our case. I believed that I was passed stonz and descent was now allowed. I did not knowingly or intentionally descend prior to stonz. Stonz was not displayed on the map when I began descent. No matter the cause; there needs to be a way to determine fix passage when a turn begins prior to a non-flyover fix.

Google
 

Original NASA ASRS Text

Title: When the flight crew of an MD-80; descending via the BRDJE RNAV STAR to DFW; began their descent from 11;000 feet to 8;000 feet as ROCKZ became their active waypoint approach control advised they had failed to cross the previous waypoint; STONZ; at the required 11;000 feet; a deviation ATC said was becoming common. The reporters believe this may happen due to the 45 degree left course change at STONZ--performed by the Lateral Nav Function of their FMS--the fact that STONZ is a 'fly by' waypoint and their aircraft's lack of automated VNAV thus requiring manual execution of the required descent; an execution for which they utilize the switch from the previous active waypoint to the next.

Narrative: I was flying pilot on this leg. While flying the BRDJE1 arrival into DFW between waypoints STONZ and ROCKZ approach control indicated that we began our descent from 11000; the STONZ crossing altitude; for 8000 feet; the ROCKZ crossing altitude prior to reaching STONZ. She provided a phone number to call to discuss the 'deviation' upon arrival. The phone discussion revealed that there have been many of these supposed deviations with these new arrivals and of course everyone is trying to figure out why.During the entire arrival I determined my proper altitude as related to each fix and when I could begin further decent by the act of the fix disappearing from the map display. When the fix disappeared; I had crossed the fix. When the STONZ fix disappeared as the GFMS cycled to the next waypoint I began descent to 8000 feet.I would like to discuss generically what I think is a general issue with these arrivals and then discuss more specifically our situation.Having given the situation some thought I think what is occurring is that because STONZ is not a fly over fix the GFMS is computing a turn that begins before STONZ to establish the track to ROCKZ. When it begins this turn the STONZ waypoint disappears as the GFMS cycles to the next waypoint. The STONZ waypoint is disappearing from the map indicating fix passage before actually reaching the fix. This cues pilots that descent is allowed to next altitude. Depending on how the GFMS computes when to start this turn the STONZ fix could disappear earlier or later than standard so as to join the track to ROCKZ. There is no other way to know when you actually are past STONZ since the distance to waypoint is now showing info for ROCKZ. Apparently this is happening a lot with manual descents not having or using vnav capability. If one happens to see the distance to waypoint figure at the instant before cycling to the next waypoint a guess could be made as to when that waypoint would be passed. This would still just be a guess and not good enough. Because of the way these arrivals are constructed and with the variations in ATC constraints given for heading; speeds and 'direct to' clearances; pilots are becoming spring loaded to get on with descents as soon as possible. When the GFMS cycles to the next fix we really want to go down so as not to miss a crossing. I have needed to use spoilers more in the last couple of months than in the previous 20 years of MD80 flying. We need in the MD80 a way to know when we are actually past the fix when it starts the turn prior to the fix. Alternatively; these fixes need to be fly over fixes so that we will always know our distance to waypoint.In our particular situation I believe that an equipment malfunction could have contributed to an early descent. Enroute we noted that there was no wind arrow displayed on the navigation display. Looking at the progress page on the GFMS it showed an erroneous wind speed of between 700 and 850 knots. I believed that the GFMS excluded this information as unreasonable and was the reason why the wind arrow was not displayed. The position of the aircraft was crossed checked with VOR information and was completely accurate. The progress page did show a groundspeed figure as computed from the GPS. This ground speed was correct when compared to the flight plan groundspeed figure and our calculated groundspeed. I could not locate a QRH procedure for this situation. We had no GFMS messages or MAP flags or messages. I believed the GFMS position to be accurate and the groundspeed indicated to be correct.Believing that the GFMS knew where it was going and how fast it was going and absent any QRH procedure directing not to use RNAV procedures I didn't feel that we had a degradation in NAV capability to declare. I can find no reference in our manuals about how the GFMS actually determines when to start a turn. I presumed that it is based on our groundspeed. If it indeed takes into account the calculated winds then that would cause it to calculate a turn at the wrong distance if using that bad wind calculation data. This could have caused an early turn for us and the cycling of the waypoints early in our case. I believed that I was passed STONZ and descent was now allowed. I did not knowingly or intentionally descend prior to STONZ. STONZ was not displayed on the map when I began descent. No matter the cause; there needs to be a way to determine fix passage when a turn begins prior to a non-flyover fix.

Data retrieved from NASA's ASRS site and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.