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/3K67Q7IKPL5Y2RIXFGNHB6TBX4IYMCMD/?format=api",
    "mailinglist": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/?format=api",
    "message_id": "[email protected]",
    "message_id_hash": "3K67Q7IKPL5Y2RIXFGNHB6TBX4IYMCMD",
    "thread": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/thread/3K67Q7IKPL5Y2RIXFGNHB6TBX4IYMCMD/?format=api",
    "sender": {
        "address": "matt (a) ettus.com",
        "mailman_id": "fcfbe2ace2e140b5be16e4b6f8dcea6b",
        "emails": "https://mailman.amsat.org/hyperkitty/api/sender/fcfbe2ace2e140b5be16e4b6f8dcea6b/emails/?format=api"
    },
    "sender_name": "Matt Ettus",
    "subject": "[eagle]  DCP Bands",
    "date": "2006-09-10T19:24:58Z",
    "parent": null,
    "children": [
        "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/QOOOVY4QINW76HJ2JCKCL5AUWA6YDR2S/?format=api"
    ],
    "votes": {
        "likes": 0,
        "dislikes": 0,
        "status": "neutral"
    },
    "content": "\n\nIn the time since the San Diego meeting, I have come to realize that:\n\n1 - Nothing is ever final.\n\n2 - The decision about bands for the DCP (digital communications \npayload) is likely to be made in some combination of the following \nvenues, in none of which you are likely to find me:\n    A - AMSAT-BB\n    B - AMSAT Board Meetings\n    C - Meetings with shadowy DoD figures without names\n    D - IARU, ITU, ARRL, QCWA, or Wuoff-Hong Society meetings\n\n3 - Many of the decision makers (especially those speaking the loudest) \nthink that SSB is the way of the future and Shannon's Law means that sex \noffenders have to register with the police.\n\n4 - It really doesn't matter to me which bands are chosen, as long as \nthey meet certain basic criteria.\n\nIn that spirit, I decided to distill the major technical constraints \nwhich we agreed on at the San Diego meeting, in order to give a basic \nset of rules which would provide us a workable bandplan for this \nsatellite.  The only legal/regulatory constraint I applied to this list \nis that we are unlikely to GAIN privileges.  Someone else can decide how \nlikely we are to lose them.\n\nThe constraints, and their reasons, as I see the consensus from the SD \nmeeting:\n\n1 - The uplink band must be chosen from the set of { L, S1, S2, C }.\n    The lower bands simply don't have the bandwidth necessary for what \nwe want to do, and would have unwieldy antennas.\n    The higher bands are much more difficult due to the pointing \naccuracy required for antennas and the difficulty of generating \nsignificant power and low noise figures.\n\n2 - The downlink band must be chose from the set of { S1, S2, C }.\n    The same reasons as constraint #1, with the added constraint that \nL-band is not legal for downlink (which falls under the \"we're not \nlikely to GAIN privileges\" category).\n\n3 - The uplink and downlink bands must be distinct.  This means no C-C \nor S1-S1.\n    The bands are simply too narrow to allow for practical duplexers in \nthe quantity we are talking about (~36).\n\n4 - The uplink band must not be used by any other payload on Eagle as a \ndownlink.\n    Obvious interference issues.\n\n5 - The downlink band should not be used by any other payload as an uplink.\n    Obvious interference issues.\n\n6 - Sharing of uplink bands or downlink bands MAY be possible, but \nprobably isn't necessary.\n\nTaking constraints 1-6 together, the choices are (in the form A/B where \nA is up, B is down):\n    {  L/S1, L/S2, L/C, S1/S2, S1/C, S2/S1, S2/C, C/S1, C/S2 }\n\n\nIn addition to the above \"hard facts\", we can add in the following \nconcerns which were expressed at the meeting:\n\n7 - We would prefer not to use S1 as a downlink because of possible \ninterference from WiFi devices.\n8 - Fear of L being taken away\n9 - Uncertain legality of S2 in ITU Region 1\n\nThis leads to the following matrix, which I believe effectively boils \ndown the decision process from the SD meeting:\n\nBandplan       7          8       9\nL/S1               X        X\nL/S2                          X       X\nL/C                           X\nS1/S2                                  X\nS1/C             \nS2/S1             X                  X\nS2/C                                    X\nC/S1              X\nC/S2                                    X \n\nThe only bandplan with no X's is S1/C, which is what we chose at the \nmeeting.  Obviously, there are now additional concerns which have been \nraised:\n    - S1-Uplink being taken away\n    - #8 not being as big a deal as we thought. \n\nThis would change the matrix.\n\nI welcome your thoughts, especially if you feel I have misrepresented \nthe SD meeting consensus.\n\nThanks,\nMatt, N2MJI\n\n",
    "attachments": []
}