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/4OZNSADRO4RNTGSMCZVY2EAACPR5PW6L/?format=api",
    "mailinglist": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/?format=api",
    "message_id": "[email protected]",
    "message_id_hash": "4OZNSADRO4RNTGSMCZVY2EAACPR5PW6L",
    "thread": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/thread/BXKOM26RJRGWBUORJY7PBWLTL2QAJH6S/?format=api",
    "sender": {
        "address": "antonio (a) qualcomm.com",
        "mailman_id": null,
        "emails": null
    },
    "sender_name": "Franklin Antonio",
    "subject": "[eagle] Re: Eagle Microwave Antenna Arrays -- RF concepts",
    "date": "2007-04-02T21:56:39Z",
    "parent": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/HW5KQG4JNJD3GBNN3ZDAW64YEIWW5POT/?format=api",
    "children": [],
    "votes": {
        "likes": 0,
        "dislikes": 0,
        "status": "neutral"
    },
    "content": "At 11:30 AM 4/2/2007, Alan Bloom wrote:\n>The other issue is that the phase shifter needs a full 360-degree\n>range.  It would be easy to do at the reference frequency with an NCO.\n\nIt is easy to get full 360 degree phase control.  You just buy this \nchip that does it.\n\nIt is also possible to put the phase shifter before the PLL, in which \ncase you do not need 360 degree phase control, but 360/n where n is \nthe PLL multiplication factor.\n\n>Good phase noise shouldn't be too hard.  With a high reference frequency\n>you can use a wide loop bandwidth and basically get the same phase noise\n>as the reference +20log(Frf/Fref).\n\nYep.  There are a couple of issues here.  I would do the data \nmodulation after the PLL, although it can be done either way.  If the \ndata modulation is done before the PLL, you would want the PLL \nbandwidth to be many times wider than the modulation, because you \nwant the PLL output phase to change in a small fraction of a \nmodulation symbol time.  (The numbers might work out ok.)  If you put \nthe modulation after the PLL then the modulation puts no constraint \non the PLL loop bandwidth.  Why would you care?  Well because if we \nhave a 1 Msymbol/sec modulation, and you want the phase to change in \nless than 1/10th of a modulation symbol, then you might choose a PLL \nbandwidth 20x the modulation rate, which would get you to 20MHz, but \nif the reference frequency of the PLL is only 100 MHz, and you want \nthe bandwidth of the PLL to be a small fraction of the reference \nfrequency (sampling issue) then you're already stuck with limited \nchoices.  Might work ok, but its not like there's a lot of room, but \nyou'd need more careful analysis.  I prefer an approach with a lot of \nroom, and easy analysis, so I was preferring the modulation after the \nPLL approach.\n\nAs for phase noise, as long as the PLL loop bandwidth is wider than \nthe modulation, then the phase noise THAT MATTERS (ie the phase noise \nwithin the modulation bandwidth) will be controlled by the reference, \nnot the VCO in the PLL.\n\nI forget what our modulation symbol rate was gonna be.  Suppose it is \n1 Msymbol/second.  Then the loop bandwidth needs to be wider than \nabout 1 MHz to ensure that the phase noise is dominated by the \nreference, and that seems trivially easy to accomplish.  Hey, you can \nthrow a factor of 2 or 3 in there for good measure.  A 3 MHz loop \nbandwidth works out fine with a 100 MHz reference frequency, as that's 33:1.\n\nSo phase noise would seem to be not a problem.  You can use cheap \nVCOs.  The loops are wide enough to make 'em track the reference.\n\n",
    "attachments": []
}