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/VC2MRHG7F4ITJCXTLSGAVAA3XZBAHZRH/",
    "mailinglist": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/",
    "message_id": "[email protected]",
    "message_id_hash": "VC2MRHG7F4ITJCXTLSGAVAA3XZBAHZRH",
    "thread": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/thread/VC2MRHG7F4ITJCXTLSGAVAA3XZBAHZRH/",
    "sender": {
        "address": "pa3guo (a) upcmail.nl",
        "mailman_id": null,
        "emails": null
    },
    "sender_name": "PA3GUO",
    "subject": "[amsat-bb] Re: O/OREOS TLE errors ?",
    "date": "2010-11-30T21:32:20Z",
    "parent": null,
    "children": [],
    "votes": {
        "likes": 0,
        "dislikes": 0,
        "status": "neutral"
    },
    "content": "Btw \n\nTHAT was indeed the fix (changing the 6/5 into 2/3) !\n\nHenk\n\n---- Ryan Caron <[email protected]> schreef:\n> The O/OREOS TLEs consistently do not have valid checksums (last digit of \n> each line). I submitted a comment about this on their website but I have \n> not heard back. The correct checksums are 2 & 3, and not the 6 & 5 that \n> is listed.\n> \n> If, by the time you read this, the posted TLEs are not 6 & 5, then the \n> TLEs have been updated and you'll have to generate new checksums. The \n> formula is a sum of all numerical characters on the line, including the \n> line number, treating minus signs as a one and everything else (letters, \n> +, spaces) as a 0. Then take modulus 10 of the sum (i.e. last digit of \n> the sum). Look it up on wikipedia for more details.\n> \n> I've made a spreadsheet to fix this, but it is still a manual operation \n> for me (got to write a script at some point). Some programs disregard \n> the the checksum, which is why HRD & the website still work and your \n> tracking tool doesn't. Predict/GPredict, my tools of choice, require \n> valid checksums, making proper TLEs a pet peeve of mine. I don't know \n> what NOVA's up to.\n> \n> In terms of \"swarm spread\" (i.e. how small delta-V between spacecraft \n> that shared the same ride, which in this case is just done by compressed \n> springs, translates into spatial differences), 35 minutes of separation \n> is pretty high for just 10 days after launch. With all the latest TLEs \n> from the three websites, I show O/OREOS being 3.5 minutes ahead of RAX, \n> and RAX being a 1.33 minutes ahead of FAST1/2.\n> \n> Ryan, KB1LKI\n> \n> On 11/30/10 4:54 AM, [email protected] wrote:\n> > ------------------------------\n> >\n> > Message: 4\n> > Date: Mon, 29 Nov 2010 22:55:16 +0100\n> > From: PA3GUO<[email protected]>\n> > Subject: [amsat-bb]  O/OREOS TLE errors ?\n> > To:[email protected]\n> > Message-ID:<[email protected]>\n> > Content-Type: text/plain; charset=utf-8\n> >\n> > Dear all,\n> >\n> > I keep on having troubles with the O/OREOS kepler sets.\n> > RAX and the others are fine.\n> >\n> > With todays version (as from the O/OREOS dashboard on the web)\n> > - NOVA gives O/OREOS just a bit behind RAX\n> > - HamRadioDeluxe give O/OREOS 35 minutes behind RAX\n> > - The O/OREOS web (dashboard graphic) shows O/OREOS 35 minutes behind RAX\n> > - My private antenna tracking tool does not recognize the keplerset of O/OREOS\n> >\n> > Anyone else has experienced this (and maybe even a solution) ?\n> > Henk\n> > --\n> > Henk, PA3GUO\n> >\n\n--\nHenk, PA3GUO\n\n",
    "attachments": []
}