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/73CDATUWQCC6WQIVIUQ7MXPEGQRDUNH4/",
    "mailinglist": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/",
    "message_id": "[email protected]",
    "message_id_hash": "73CDATUWQCC6WQIVIUQ7MXPEGQRDUNH4",
    "thread": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/thread/XY2HCSQAOGHO3LPQV7UDN6U2REJNEJMR/",
    "sender": {
        "address": "daniel (a) destevez.net",
        "mailman_id": "c2eac82b839b45f5a7d3b923c1721007",
        "emails": "https://mailman.amsat.org/hyperkitty/api/sender/c2eac82b839b45f5a7d3b923c1721007/emails/"
    },
    "sender_name": "Daniel Estévez",
    "subject": "Re: [amsat-bb] How to tame gr-satellites?",
    "date": "2019-09-17T23:15:59Z",
    "parent": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/YYFXUG7CLXAYB7CW6UD52OU6I7REZTZZ/",
    "children": [
        "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/HUX3753XSEWYSKUITNUKURCEOC5PU2GD/"
    ],
    "votes": {
        "likes": 0,
        "dislikes": 0,
        "status": "neutral"
    },
    "content": "Hi Hans,\n\nI'm taking your email as constructive criticism, so I'll discuss on\nideas about how to improve the documentation or procedures rather than\non how many people use GNU Radio or gr-satellites and whether this is\nsatisfactory.\n\nOne problem is that some things that might seem so obvious when you are\nreally involved with some software/framework are not obvious at all for\nnewcomers. With these things, many times a few extra sentences in the\ndocumentation can help a lot. And usually the best advice comes from\nnewcomers: the pitfalls they found and how to help others avoid them.\n\nThis said, answers to particular points below.\n\nEl 17/9/19 a las 8:58, Hans BX2ABT escribió:\n\n> On the gr-satellites github page it says you need to fulfill some\n> dependency requirements before compiling gr-satellites.\n> \n> [quote]\n> \n>   * Phil Karn's KA9Q |libfec|. A fork that builds in modern linux\n>     systems can be found here <https://github.com/daniestevez/libfec>.\n>   * construct <https://construct.readthedocs.io/en/latest/>, at least\n>     version 2.9.\n>   * requests <https://pypi.org/project/requests/2.7.0/>.\n>   * swig <http://www.swig.org/>\n> \n> [/unquote]\n> \n> The above is very ambiguous. It indicates \"why\" but not \"how\".\n> \n> 1) Do I have to compile and install all this myself, or can they be\n> found in my distro's repositories?\n> \n> 2) Are they all installed with ./configure, make, make install or are\n> there other methods?\n> \n> The answers are (I think, but not sure):\n> \n> 1) You do have to compile and install the first three, but you can use\n> swig from you distro's repository.\n> \n> 2) libfec is compiled with ./configure, make, make install. Construct\n> and requests can be found in distro's repositories but are probably\n> older versions and they are called (on Debian systems) python-construct\n> and python requests. So the best way to go is to install by using pip.\n\nThe problem with this is that it depends a lot on what particular\ndistribution or setup you are using. Maybe your distribution ships a\nrecent version of GNU Radio and you installed that. Maybe you compiled\nit from source. Maybe swig came as a dependency as you installed GNU\nRadio. Maybe not and you need to install it explicitly. Maybe your\ndistribution has packaged recent enough versions of construct or\nrequests. Maybe not and you are better off using pip. Or maybe you\nPython installation is based on Anaconda, so you install all Python\npackages using conda. Or maybe you used PyBOMBs to install GNU Radio and\ngr-satellites instead of your distributions' package manager. Or maybe\nyou are using Arch, which has an AUR package for gr-satellites.\n\nCertainly it is hard (especially for a single person) to give precise\ninstructions covering all these use cases.\n\nHowever, I see a couple possible solutions:\n\n1) Identify the case that typically should work for most people. This is\nmore or less what you said: install GNU Radio, SWIG and requests through\nyour package's manager, install construct through pip, install libfec\nfrom source, and install gr-satellites from source.\n\nI think this would be the recommended steps in Ubuntu 19.04, which seems\nthe most popular distribution, and is also what I'm doing on Gentoo.\n\n2) Try to get help from the community to describe precise installation\nsteps for different distributions and/or setups. Actually Github\nsupports Wiki pages for the repositories. I'm not currently using this\nfeature, but perhaps it could be useful to open up an \"Installation\"\nwiki page where people can detail installation steps for different distros.\n\nI think option 2) might be more desirable, but I'm not sure if I could\nget enough people to engage and maintain good quality and up to date\ninstructions (this is important as new distros get released).\n\nOption 1) might be much easier to set up and could be accomplished by\nadding an \"Installation of dependencies\" section to the README.\n\nI agree that having some installation instructions that you can simply\ncopy & paste onto the command line can save time and effort even to very\nexperienced people.\n\n> Another example. I've got GNU Radio and gr-satellites installed and I\n> figured out where the .grc files were hiding. I open one and am greeted\n> with loads of red because of missing blocks. There is also another\n> warning that says \"Port is not connected\". I've been reading and\n> searching the web for two hours already, but still haven't got a clue\n> about the \"why\" and certainly not about \"how\" to proceed now. I don't\n> mind trouble shooting, but then I need at least some hints to get\n> started. Right now I haven't.\n\nThis might be because you haven't installed the hierarchical flowgraphs.\nIt is described in the README. Ideally I would like this step to run\nautomatically from CMake, but I haven't been able to find how.\nTherefore, it needs to be run manually. Maybe with the updated CMake\ninfrastructure in GNU Radio 3.8 it will be easier to do this automatically.\n\nIf you have indeed installed the hierarchical flowgraphs and are getting\nmissing blocks, please detail which blocks are missing.\n\n> Third example: last year I did have a working GNURadio/gr-satellites\n> setup with pyBOMBS (before that broke). I did see some telemetry rolling\n> down a terminal window, but the last block in every flow graph is always\n> this SatNogs Telemetry Forwarder. Tried to figure out if it was actually\n> forwarding, where it ended up, where I could see my forwarded data.\n> Couldn't figure it out, couldn't find any documentation or examples, so\n> I gave up.\n\nThere is also either a telemetry parser block or a debug message block\nas last block (in parallel with the telemetry forwarder) which is in\ncharge of printing the telemetry values that appear in the terminal window.\n\nRegarding the SatNOGS telemetry forwarder, this is documented in the\nREADME, in a section called \"Submitting telemetry to SatNOGS\", which I\nthink already answers some of your questions.\n\nAs you'll see, you need to specify your callsign and location to submit\ntelemetry to SatNOGS, so unless you did set these, then the forwarder\nwas simply doing nothing.\n\nThe questions that occur to me that are not explicitly treated in the\ndocumentation are:\n\n* How do I know if this is working? It happens that the forwarder will\nprint nothing when a frame is submitted correctly. However, if there is\nsome error, the forwarder will print an error message. I figured out\nthis was the most useful approach, as it would be too verbose to print\nout a message anytime that a packet is submitted successfully. However,\nas this design choice is not obvious, perhaps a sentence should be added\nto the documentation.\n\n* Where do the frames end up in SatNOGS DB. Of course the answer is that\nyou need to got to SatNOGS DB webpage, select the particular satellite,\nscroll to the bottom, and there you have some links to download the\nframes in the database (which in my experience might or might not work\ndepending on how much data you request). However, I think that this\nfunctionality should be documented from SatNOGS side rather than from\nthe gr-satellites side. Somehow, in the 2Submitting telemetry to\nSatNOGS\" section of the README it is assumed that you know what SatNOGS\nDB is.\n\n\nSo to wrap up:\n\nIt is possible to create a Wiki page on Github were people can\ncontribute with documentation to help others (installation instructions,\nsetup descriptions, interfacing with other software). I can set this up.\nWould be people interested in contributing?\n\nRegarding the README, I'm open for pull requests with improvements or\nwith concreted ideas about how to improve it.\n\n73,\n\nDani.\n",
    "attachments": []
}