Email Detail

HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "url": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/FFHPD5AO4S7W5G6EZNVZG2KUH7TEI5WH/?format=api",
    "mailinglist": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/?format=api",
    "message_id": "[email protected]",
    "message_id_hash": "FFHPD5AO4S7W5G6EZNVZG2KUH7TEI5WH",
    "thread": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/thread/NHX6X5EKQIQSZSS634TXEOLCBVH3Q3HB/?format=api",
    "sender": {
        "address": "bill (a) hsmicrowave.com",
        "mailman_id": "d7ecbf0c1df148f289f27dd7a8c37974",
        "emails": "https://mailman.amsat.org/hyperkitty/api/sender/d7ecbf0c1df148f289f27dd7a8c37974/emails/?format=api"
    },
    "sender_name": "Bill Ress",
    "subject": "[eagle] Re: Eagle 10 MHz Clock",
    "date": "2007-04-11T17:41:24Z",
    "parent": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/FXVUYCDRZ4NODIH4SFOVW5FVH22M72XW/?format=api",
    "children": [
        "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/EUCI7IIYEEW5XGZ55ZIOF5B6JCQL3E2Z/?format=api"
    ],
    "votes": {
        "likes": 0,
        "dislikes": 0,
        "status": "neutral"
    },
    "content": "Thanks for the clarification on the past command receivers.\n\nI agree with you fully about the frequency agility issue. If it's not \nneeded for a mission function, then it could be more of headache than a \nfeature. But then some of the receivers on AO-51 are agile and I'm not \naware of any issues.\n\nOn the S2 Receiver - the LO is \"not\" agile and likewise for the C \nTransmitter LO. The prototype is using a synthesizer chip (Peregrine \nPE3341) but it's EEPROM programmed before installing onto the PCB. Yes - \nI know about the EEPROM radiation issue but I have a fall back position \nwith the \"hardwired\" version if it becomes a real problem.\n\nLyle Johnson wrote:\n> Hello Bill!\n>\n>> Good points about keeping the command receiver on 100% - no issue \n>> there. But I think the matter is somewhat confused (at least for me) \n>> since I believe the command receiver that John has designed is also \n>> the data/analog receiver. I don't recall that being the case is the \n>> past satellites. If command and data function stay combined, then \n>> that's all the more reason for considering John's suggestion.\n>\n> In the past, the \"command receiver\" used the same front end as the \n> transponder receiver.  The difference was an IF tap that was then \n> downconverted to baseband to drive a hardware command decoder.\n>\n> Thus, all uplink that had command capability had receivers that were \n> always on.\n>\n> One rule learned the hard way is you *never* turn off a command \n> receiver. It's also why command receivers, at least, were never \n> frequency agile.  It's bad enough to recover a spacecraft if you are \n> commanding it in the blind - it's even hardware if you have no idea \n> where the receiver might be tuned.  So, we always used crystal \n> oscillator/multipliers, or PLLS with pins-selection of dividers.  \n> Using a serial-load PLL adds a lot of risk -- not sure what the reward \n> is for the risk.\n>\n> Not to say we need to always do what worked in the past, just that we \n> should have compelling reasons to change things that relate to \n> spacecraft safety and health.\n>\n> 73,\n>\n> Lyle KK7P\n>\n>\n\n",
    "attachments": []
}