Show an email

GET /hyperkitty/api/list/[email protected]/email/I3JSSJQR424MW5VQ7U6XJ7FBRITHYLEJ/?format=api
HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "url": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/I3JSSJQR424MW5VQ7U6XJ7FBRITHYLEJ/?format=api",
    "mailinglist": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/?format=api",
    "message_id": "[email protected]",
    "message_id_hash": "I3JSSJQR424MW5VQ7U6XJ7FBRITHYLEJ",
    "thread": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/thread/7I3D5KTJRCLUSIEJUCZRICC56YWF6ZY7/?format=api",
    "sender": {
        "address": "karn (a) philkarn.net",
        "mailman_id": null,
        "emails": null
    },
    "sender_name": "Phil Karn",
    "subject": "[amsat-bb] Re: Turn off AGC when receiving BPSK-1000",
    "date": "2011-08-18T02:13:33Z",
    "parent": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/LLKSKQ4MMJSH37O5SF7K6HO7IWBNGQSY/?format=api",
    "children": [],
    "votes": {
        "likes": 0,
        "dislikes": 0,
        "status": "neutral"
    },
    "content": "On 8/17/11 4:24 PM, Alan Cresswell wrote:\n\n> That's interesting.  I have collected all my passes on the TS2000 with the\n> AGC on and set to the longest setting.  This is mainly because I often\n> record the signal level every 0.5 seconds during a pass which requires the\n> AGC to be on and the longest setting irons out any short fades.\n\nThe main thing is that the gain remain constant, or nearly so, during\neach fade so that the random series of 0's and 1's produced during the\nfade on thermal noise is mostly seen as 'weak' 0's and 'weak' 1's.\nIncreasing the gain during a fade makes those random bits seem stronger\nand more certain when they're still just random bits. That can make it\nharder for the Viterbi decoder to correct them as errors.\n\nA Viterbi decoder works much like a network routing algorithm that looks\nfor the cheapest path to a destination. It finds the best path through a\n'trellis', a pattern of links corresponding to all possible state\ntransitions in the convolutional encoder that produced the transmitted\nsignal. Out of every possible path the decoder finds the one that most\nclosely matches the received sequence and declares it as the one that\nwas most likely sent. It can still be wrong, and when it does it usually\nemits a burst of several dozen errors until the decoder gets back on the\nright path. In BPSK-1000, this error burst causes the HDLC decoder to\nabort the current frame or discard it with a CRC error.\n\nThe Viterbi decoder tallies up the 'cost' of each link in a path to find\nits total 'path cost'. If a particular link assumes that a '0' was sent,\nthen receiving a strong '0' is the best possible match so that results\nin the lowest possible cost for that link. A weak '0' gives a greater\ncost, a weak '1' an even greater cost, and a strong '1' gives the\nhighest possible cost.\n\nEven if one link in a path has a high cost, the complete path will still\nbe chosen as the winner if all the other paths are worse. When this\nhappens, typically all the other links in the path will closely match\nthe received sequence.\n\nSo you really want to avoid classifying bits as 'strong' when you know\nthe signal is gone and the bits can't possibly be right. That means not\nboosting the gain (and the noise level) during a fade. The noise level\nshould be kept constant.\n\n-Phil\n",
    "attachments": []
}