Thanks for the clarification on the past command receivers.
I agree with you fully about the frequency agility issue. If it's not needed for a mission function, then it could be more of headache than a feature. But then some of the receivers on AO-51 are agile and I'm not aware of any issues.
On the S2 Receiver - the LO is "not" agile and likewise for the C Transmitter LO. The prototype is using a synthesizer chip (Peregrine PE3341) but it's EEPROM programmed before installing onto the PCB. Yes - I know about the EEPROM radiation issue but I have a fall back position with the "hardwired" version if it becomes a real problem.
Lyle Johnson wrote:
Hello Bill!
Good points about keeping the command receiver on 100% - no issue there. But I think the matter is somewhat confused (at least for me) since I believe the command receiver that John has designed is also the data/analog receiver. I don't recall that being the case is the past satellites. If command and data function stay combined, then that's all the more reason for considering John's suggestion.
In the past, the "command receiver" used the same front end as the transponder receiver. The difference was an IF tap that was then downconverted to baseband to drive a hardware command decoder.
Thus, all uplink that had command capability had receivers that were always on.
One rule learned the hard way is you *never* turn off a command receiver. It's also why command receivers, at least, were never frequency agile. It's bad enough to recover a spacecraft if you are commanding it in the blind - it's even hardware if you have no idea where the receiver might be tuned. So, we always used crystal oscillator/multipliers, or PLLS with pins-selection of dividers. Using a serial-load PLL adds a lot of risk -- not sure what the reward is for the risk.
Not to say we need to always do what worked in the past, just that we should have compelling reasons to change things that relate to spacecraft safety and health.
73,
Lyle KK7P