Narrative:

We were notified the day prior that our ASR was going to be out (1 second updates) for maintenance and would have to be on apple valley radar (12 second updates) for an extended period of time. RNAV stars were in use but due to our current configuration; the RNAV map/overlay for our scopes were not available. So our ability to ensure that the RNAV altitude windows were being met; were non existent. When I asked the flm; she gave me a piece of paper with the restrictions. I could foresee to some extent what was going to happen within the next hour. With these opd's in use with apple valley radar; I knew it was a recipe for potential conflicts. There were too many variables to keep track of with a 12 second update. I suggested to the flm that 'knock it off procedures' be implemented. The OM and tmu were steadfast in their ways and wanted to stay the course. The end result was terrible. ZMP 21 was constantly coordinating speeds and overtakes to the 'I' controller and she became overwhelmed; resulting in a few late frequency changes. With the opd's in play; there is no built in separation between crossing stars. I had to take numerous aircraft off the stars to get some kind of concrete altitude separation. With most of the aircraft descending from flight levels; its's difficult to gauge and decide whom to level and or slow. And when you do decide; it takes a considerable amount of time for it to take place. I was given an aircraft from 'I' on the kkilr arrival descending to 110 and I had aircraft from the nitzr/bluem arrivals doing the same. The 'I' controller was so overwhelmed with ZMP calling and trying to sequence herself that she forgot to transfer communication. To keep standard separation; I had to bust airspace. The entire session was terrible and could have been avoided if management was receptive to real world input. There was only one that I saw that could have been a loss of separation; but I'm sure there were more that I did not see.I recommend that when we are in apple valley radar; that we implement 'knock it off' procedures. And also fix our RNAV stars. They are far from being adequate. In our 7110.65; I don't recall anything about providing 'fuel efficient' service. I understand that we have to be more environmentally concerned; and give the user what they want. They want to cut costs; reduce delays; and be more efficient. But with these opd's in use; there is too much of a gray area of altitude crossings and that affects speed. It seems to be unsafe sometimes and definitely not 'fuel efficient' when I have to give restrictions because of sequence and or overtake just entering the M98 airspace. Aircraft come in to high and too fast.

Google
 

Original NASA ASRS Text

Title: M98 controller describes a day that the normal radar was out and they had to use another site that gave 12 second updates instead of the usual 1 second updates. According to the reporter the procedures in place did not work. There were many deviations and they had to separate traffic on various STARs. Controller requested a procedure which he felt would have made the traffic manageable; but was not approved by management and Traffic Management Coordinator.

Narrative: We were notified the day prior that our ASR was going to be out (1 second updates) for maintenance and would have to be on Apple Valley radar (12 second updates) for an extended period of time. RNAV STARS were in use but due to our current configuration; the RNAV map/overlay for our scopes were not available. So our ability to ensure that the RNAV altitude windows were being met; were non existent. When I asked the FLM; she gave me a piece of paper with the restrictions. I could foresee to some extent what was going to happen within the next hour. With these OPD's in use with Apple Valley radar; I knew it was a recipe for potential conflicts. There were too many variables to keep track of with a 12 second update. I suggested to the FLM that 'Knock it off procedures' be implemented. The OM and TMU were steadfast in their ways and wanted to stay the course. The end result was terrible. ZMP 21 was constantly coordinating speeds and overtakes to the 'I' controller and she became overwhelmed; resulting in a few late frequency changes. With the OPD's in play; there is no built in separation between crossing STARS. I had to take numerous aircraft off the STARS to get some kind of concrete altitude separation. With most of the aircraft descending from flight levels; its's difficult to gauge and decide whom to level and or slow. And when you do decide; it takes a considerable amount of time for it to take place. I was given an aircraft from 'I' on the KKILR arrival descending to 110 and I had aircraft from the NITZR/BLUEM arrivals doing the same. The 'I' controller was so overwhelmed with ZMP calling and trying to sequence herself that she forgot to transfer communication. To keep standard separation; I had to bust airspace. The entire session was terrible and could have been avoided if management was receptive to real world input. There was only one that I saw that could have been a loss of separation; but I'm sure there were more that I did not see.I recommend that when we are in Apple Valley radar; that we implement 'knock it off' procedures. And also fix our RNAV STARS. They are far from being adequate. In our 7110.65; I don't recall anything about providing 'Fuel Efficient' service. I understand that we have to be more environmentally concerned; and give the user what they want. They want to cut costs; reduce delays; and be more efficient. But with these OPD's in use; there is too much of a gray area of altitude crossings and that affects speed. It seems to be unsafe sometimes and definitely not 'fuel efficient' when I have to give restrictions because of sequence and or overtake just entering the M98 airspace. Aircraft come in to high and too fast.

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.