@DL4PD: I got into this situation for a number of reasons:
First because I want to learn about SDR and DSP. I have the SatNOGGS image running on a RPi. It works well, but I felt that I didn’t learn anything from it. So I decided to try to build it on my workstation (running OpenSUSE Leap 42.3), so I could better study it, possibly eventually doing my own things using e.g GRC.
Second out of ignorance. I cloned the code from Gitlab and followed this installation instruction It talks about setting up ‘the’ virtual environment. Not knowing the implications of doing this I set up a virtual environment. It later turned out that the environmet is Python3. At that time i had not realized that SatNOGS use Python2, so I plunged ahead - running into some of the incompatibilities between Python2 and Python3
I thought (naively) that being a rather young project SatNOGS would have opted for Python3 but I guess there are good reasons for sticking to Python2. Personally I have chosen Python3 for my own programming, because I believe that at a certain time Python2 will be obsoleted and eventually abandoned. So I chose Python3 - just like I have chosen to use systemd, because it is the coming thing.
Anyway, I’m not religious about Python versions so I’ll switch to Python2. I guess that I can do that by deleting everything I have done so far, reclone from Gitlab, not set up the virtual environment (OpenSUSE has Python2.7 as default) and I should be in business.
I have redone the installation of satnogs-client, this time paying close attention, so it became a Python 2.7 installation. I had to specify pip2 in the ‘pip install -e .’ command.
So now my observations are being uploaded - at least the audio files. I’m still have a few minor problems with the waterfalls, but they should be solved by now (missing gnuplot - /usr/share vs. /usr/local/share)
So onward and upwards to new problems - no, call them challenges.
@n5fxh and @DL4PD: Thanks for taking the time to help me.
I this case it should be easy: The culprit is the waterfall configuration script ‘satnogs_waterfall.gp’. It is the only script located in /usr/share/satnogs/scripts (or /usr/local/share/satnogs/scripts as is the case for me). So you could introduce a varaiable (in settings.py?) called e.g. SATNOGS_SCRIPT_PATH and then change the ‘plot_waterfall’ method in observer.py to use settings.SATNOGS_SCRIPT_PATH rather than the hardwired path it uses today.
However, I’m not familiar with the developments process for the SatNOGS project so I hesitate. Perhaps you (I know from OZ9AEC that you are one of the developers) could point me in the right direction. I assume that I would have to do a git push?
For the waterfall-script: this is installed in /usr/local because it’s a “local” build! I bet you can change that somehow by adding a destination to the “make install” command.
If you would like to contribute (like me, let’s say I’m a contributor for a while, the core-developers do have ways more of experience ;)) you would have to learn about git. After your work on a specific “issue” you can do a “Pull Request” (or “PR”) for github projects or a “Merge Request” (or “MR”) for gitlab projects. This will be approved by the owner of the github project or by one of the maintainers of a gitlab project. It’s a bit of self training needed to do things the correct way and I am still learning, too. My first contact with commands beyond ‘git clone’ was as I first tried to improve something on gpredict, and it is still hard for me
If I could help on a specific problem you have: feel free to ask.
