[eagle] Re: Eagle 10 MHz Clock

[Bill Ress]

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
>
>