Re: lost comms with Pt Mugu
Posted: Sat Jan 21, 2012 7:31 pm
Steve, you shouldn't be in the least bit embarrassed. Think about the fact that you've been doing a respectable job of flying around in the IFR system when you don't hold a real world PPL or an instrument rating. It's really quite incredible to begin with. Every now and then you're going to run into a situation that's new and unfamiliar and won't necessarily know the best course of action. That's not something that should be a surprise, or cause for concern. Continue to pick up all the nuggets of information that you can and keep at it!
I'm not sure precisely what freq you actually tuned to, but generally speaking, if you were getting responses from the controller at first, and then you stopped hearing him, it means that you ended up out of the range of the transmitter. If you were assigned the correct freq and read it back correctly, then perhaps you simply mistuned it. As I mentioned above, when you checked in on the wrong freq, we'd normally catch that through our system monitoring tool, but depending on controller workload, it's possible that the subtle fact that you were calling the expected facility but on the wrong freq was missed by the controller.
This is a good one for everyone to learn from, it's interesting stuff! It speaks to the 'accident chain' theory, where there isn't a smoking gun, but rather, a series of small links in the chain that lead to an undesirable outcome....in this case, a loss of communications. The two links were (I'm guessing), tuning the wrong freq, and the controller not realizing that you were checking in on the wrong freq. Remove either one of those conditions, and the error would not occur.
I'm not sure precisely what freq you actually tuned to, but generally speaking, if you were getting responses from the controller at first, and then you stopped hearing him, it means that you ended up out of the range of the transmitter. If you were assigned the correct freq and read it back correctly, then perhaps you simply mistuned it. As I mentioned above, when you checked in on the wrong freq, we'd normally catch that through our system monitoring tool, but depending on controller workload, it's possible that the subtle fact that you were calling the expected facility but on the wrong freq was missed by the controller.
This is a good one for everyone to learn from, it's interesting stuff! It speaks to the 'accident chain' theory, where there isn't a smoking gun, but rather, a series of small links in the chain that lead to an undesirable outcome....in this case, a loss of communications. The two links were (I'm guessing), tuning the wrong freq, and the controller not realizing that you were checking in on the wrong freq. Remove either one of those conditions, and the error would not occur.