Show an email

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

{
    "url": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/T2ENQF6THYQVYLEWGOR2LQ2E2WDT2IWQ/",
    "mailinglist": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/",
    "message_id": "[email protected]",
    "message_id_hash": "T2ENQF6THYQVYLEWGOR2LQ2E2WDT2IWQ",
    "thread": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/thread/T2ENQF6THYQVYLEWGOR2LQ2E2WDT2IWQ/",
    "sender": {
        "address": "pa3guo (a) amsat.org",
        "mailman_id": null,
        "emails": null
    },
    "sender_name": "PA3GUO",
    "subject": "[amsat-bb]  KYSAT-1 TLE errors ?",
    "date": "2011-03-03T20:57:05Z",
    "parent": null,
    "children": [],
    "votes": {
        "likes": 0,
        "dislikes": 0,
        "status": "neutral"
    },
    "content": "Dave,\n\nUsing Ryans LXS I see that (like so often) the TLEs do not have a correct checksum:\nRyans XLS says it should be \n\n1 99999U 00000 11063.43259919 0.00000000 00000-0 00000-0 0 0000\n2 99999 97.9564 8.4412 0007658 67.0214 113.6793 14.77265551000005\n\nAnd not as on their website:\n1 99999U 00000 11063.43259919 0.00000000 00000-0 00000-0 0 0000\n2 99999 97.9564 8.4412 0007658 67.0214 113.6793 14.77265551000000\n\nHalf of my SW here ignores the checksum, other half simply does not show the satellite.\nThis is why I also had to correct the TLEs.\n\nPs: feel free to double-check, I am not a TLE expert\n\nHenk, PA3GUO\n\n\nI just tried using the TLEs off of the KySat-1 page, but couldn't get them\nto work, nothing showed up.\n\nhttp://ssl.engineering.uky.edu/missions/orbital/kysat1/operations/\n\nDave - KB1PVH\n\n\n-----Oorspronkelijk bericht-----\nVan: Ryan Caron [mailto:[email protected]] \nVerzonden: zondag 26 december 2010 20:29\nAan: [email protected]\nCC: PA3GUO; [email protected]\nOnderwerp: Re: [amsat-bb] O/OREOS TLE errors ?\n\nHank (and the -bb)\n\nAttached is the spreadsheet previously mentioned spreadsheet to fix TLEs checksums. I've rewritten it since what I was using was still a tedious operation and I didn't want to distribute that to the community. This should be much better, though you still need to remove any leading spaces in the lines.\n\nIt appears that O/OREOS' TLEs on their website are OK now, possibly because SpaceTrack is publishing now. My apologies for not getting this out sooner; we'll have to wait for the next launch to try this out.\n\nDuring the fog-of-war in the days after launch, I find there are often multiple TLEs for the same satellite. In this case I like to change the IDs so I can have them all loaded in GPredict simultaneously. This spreadsheet will verify that the IDs are the same for both lines, and of course regenerate the checksums.\n\nThis spreadsheet was created with OpenOffice 3.2.1, and I've exported it to Excel and checked it with MS Office XP and appears to work fine. \nPlease let me know if there are any problems.\n\nHappy holidays and 73,\nRyan KB1LKI\n\nOn 11/30/10 11:33 AM, PA3GUO wrote:\n> Hi Ryan\n>\n> Thanks a lot for your detailed reply.\n>\n> Would you be so kind to share that spreadsheet (XLS?) with me ?\n> In the coming days I really need (well, would higly appreciate) to \n> have working TLEs - especially also for Nanosail.\n>\n> Best of course would be if the O/OREOS/Nanasail team could fix this \n> prior to posting them on the web :-)\n>\n> Thanks\n> Henk\n>\n>\n> ---- Ryan Caron<[email protected]>  schreef:\n>> The O/OREOS TLEs consistently do not have valid checksums (last digit \n>> of each line). I submitted a comment about this on their website but \n>> I have not heard back. The correct checksums are 2&  3, and not the \n>> 6&  5 that is listed.\n>>\n>> If, by the time you read this, the posted TLEs are not 6&  5, then \n>> the TLEs have been updated and you'll have to generate new checksums. \n>> The formula is a sum of all numerical characters on the line, \n>> including the line number, treating minus signs as a one and \n>> everything else (letters,\n>> +, spaces) as a 0. Then take modulus 10 of the sum (i.e. last digit \n>> +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 \n>> operation for me (got to write a script at some point). Some programs \n>> disregard the the checksum, which is why HRD&  the website still work \n>> and your tracking tool doesn't. Predict/GPredict, my tools of choice, \n>> require valid checksums, making proper TLEs a pet peeve of mine. I \n>> don't know 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 \n>> compressed springs, translates into spatial differences), 35 minutes \n>> of separation is pretty high for just 10 days after launch. With all \n>> the latest TLEs from the three websites, I show O/OREOS being 3.5 \n>> minutes ahead of RAX, 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 \n>>> behind RAX\n>>> - My private antenna tracking tool does not recognize the keplerset \n>>> of O/OREOS\n>>>\n>>> Anyone else has experienced this (and maybe even a solution) ?\n>>> Henk\n>>> --\n>>> Henk, PA3GUO\n>>>\n>\n> --\n> Henk, PA3GUO\n>\n\n\n",
    "attachments": []
}