Instructions for Raspbian exist on wiki. Are you talking about other instructions?
For rasbian, these are the instructions but for fedora we have removed them without moving them to wiki.
For now we can find the fedora process here.
I think we should move it back either on wiki or docs repo until all issues with the new rasbian image are solved and it is stable like the fedora one.
@Zathras If you have the rasbian image you used can you check if rotctld process was running? ps -ax or check if port 4533 is listening with netstat -nap
I got the same error on the fresh raspbian image and I think satnogs-client requires rotctld process running, which does not happen if HAMLIB_UTILS_ROT_ENABLED is set to False(No in the configuration screen). As @Acinonyx pointed above if there is no rotator then below setting are required.
HAMLIB_UTILS_ROT_ENABLED → Yes
HAMLIB_UTILS_ROT_OPTS → -m 1
I had to set the above setting to get rid of the above error. Correct me if I am wrong. The raspbian wiki might need to be updated or satnogs-client fixed.
Another issue. Also yesterday night I was testing raspbian image again and got lot of TLS certificate errors and PI stopped responding to ssh commands and communicating with website. This started just when a CW observation started. I could not even log back in to PI. I could reproduce it three times. So frustrating.
This is peculiar. Can you elaborate on the issue? Only on CW observations or any observations? Did it become responsive again once the observations finished?
@Jferns I’m not running the raspbian image. I’m using my own Stretch with satnogs manually installed and no rotator.
Everything was fine-ish until I upgraded to satnogs-client 0.5. I tried to re-install gr-satnogs but have no idea which version I got from github.
I’m not sure if the HAMLIB will fix anything, but I will try.
If I can work out which gr-satnogs version I’m using, I might be able to get processing done.
This is peculiar. Can you elaborate on the issue? Only on CW observations or any observations? Did it become responsive again once the observations finished?
[/quote]
No It did not become responsive. again. I had to power down and power up again. I do not know if it was only for CW, I should have checked for other types. I will try again tonight.
1 Like
Via the original fedora install instructions.
git clone GitHub - satnogs/gr-satnogs: SatNOGS GNU Radio Out-Of-Tree Module
cd gr-satnogs
mkdir build
cd build
cmake -DLIB_SUFFIX=64 -DCMAKE_INSTALL_PREFIX=/usr …
make -j4
sudo make install
Has worked for me in the past until the latest upgrade to satnogs-client 0.5 Tried the above to comply with compatibility, but it broke my system
ok then for the latest version run inside gr-satnogs directory:
git pull origin master
cd build
sudo make uninstall
cd ../
rm -rf build
mkdir build
cd build
for fedora:
cmake -DLIB_SUFFIX=64 -DCMAKE_INSTALL_PREFIX=/usr ..
or for debian
cmake ../
and then:
sudo make -j4
sudo make install
Edit: Don’t forget to run
sudo ldconfig
If you want to be 100% that gr-satnogs library is linked you can run
sudo ldconfig -v | grep satnogsThanks fredy 
I ran your instructions as per debian.
running “sudo ldconfig -v | grep satnogs” I get:
ldconfig: Path /lib/arm-linux-gnueabihf' given more than once ldconfig: Path/usr/lib/arm-linux-gnueabihf’ given more than once
ldconfig: /lib/arm-linux-gnueabihf/ld-2.24.so is the dynamic linker, ignoring
ldconfig: libgnuradio-satnogs-1.0.1git.so.0.0.0 -> libgnuradio-satnogs.so
/lib/ld-linux.so.3 is the dynamic linker, ignoring
However, both VHF & UHF stations (upgraded) are now processing and uploading waterfall and audio to dev-network. I’m happy again.
I did have an issue with UHF because the preamp was faulty. Since been repaired and now working great, as per signals received
1 Like
Great to hear that everything works again.
This is the line you should look for and shows gr-satnogs library is linked successfully.
So, as your stations are ready and fully functional I suggest you start the process for moving to production (first by asking for an account here by opening a new thread).
Did you schedule any APT or FKS9k6 to see decoded data too?
APT works fine:
https://network-dev.satnogs.org/observations/7098/
FSK9K6 seems to have some issues and doesn’t upload anything:
https://network-dev.satnogs.org/observations/7081/ and https://network-dev.satnogs.org/observations/7079/.
I’m waiting to see the next one https://network-dev.satnogs.org/observations/7089/
@Zathras can you check FSK9K6 observations if they left any file in /tmp/.satnogs/data or any error in the logs?
@fredy,
no files left in /tmp/.satnogs/data it’s empty.
When I run “sudo journalctl -u satnogs-client.service” at this time 1144z, I can only see back to 0708z. Can’t view the log for 7079 05:07-05:20 or 7081 05:54-06:10. Is it possible to view back further?
Going through daemon.log, I find:
Oct 5 13:21:28 satnogs-uhf bash[715]: Usage: satnogs_fsk9600_g3ruh_ax25.py: [options]
Oct 5 13:21:28 satnogs-uhf bash[715]: satnogs_fsk9600_g3ruh_ax25.py: error: no such option: --rf-gain
But nothing similar for the 05:54-06:10 (13:54-14:10) pass, except this:
Oct 5 14:10:27 satnogs-uhf bash[715]: Exception in thread Thread-160:
Oct 5 14:10:27 satnogs-uhf bash[715]: Traceback (most recent call last):
Oct 5 14:10:27 satnogs-uhf bash[715]: File “/usr/lib/python2.7/threading.py”, line 801, in __bootstrap_inner
Oct 5 14:10:27 satnogs-uhf bash[715]: self.run()
Oct 5 14:10:27 satnogs-uhf bash[715]: File “/usr/lib/python2.7/threading.py”, line 754, in run
Oct 5 14:10:27 satnogs-uhf bash[715]: self.__target(*self.__args, **self.__kwargs)
Oct 5 14:10:27 satnogs-uhf bash[715]: File “/usr/local/lib/python2.7/dist-packages/satnogsclient/observer/worker.py”, line 127, in _communicate_tracking_info
Oct 5 14:10:27 satnogs-uhf bash[715]: self.check_observation_end_reached()
Oct 5 14:10:27 satnogs-uhf bash[715]: File “/usr/local/lib/python2.7/dist-packages/satnogsclient/observer/worker.py”, line 175, in check_observation_end_reached
Oct 5 14:10:27 satnogs-uhf bash[715]: self.trackstop()
Oct 5 14:10:27 satnogs-uhf bash[715]: File “/usr/local/lib/python2.7/dist-packages/satnogsclient/observer/worker.py”, line 168, in trackstop
Oct 5 14:10:27 satnogs-uhf bash[715]: os.killpg(os.getpgid(self._gnu_proc.pid), signal.SIGKILL)
Oct 5 14:10:27 satnogs-uhf bash[715]: OSError: [Errno 3] No such process
hm… a wild guess that logs are more rows than maximum in your terminal. Try one of the next:
sudo journalctl -u satnogs-client.service | less
That will allow you to get all the file from start and move to the end by pressing down arrow or page down. Press Q to exit.
sudo journalctl -u satnogs-client.service | grep rror
This will print only the rows with errors. Yes it misses the e in order to catch both Error and error as grep is case sensitive. if you need to check some rows above (Before) or bellow (After) that row use -A and/or -B . for example:
sudo journalctl -u satnogs-client.service | grep rror -A 2 -B 2
It will show 2 lines before and after the matched row.
Finally journalctl allows you to filter logs with some time parameters… you need to check this in its manual.
If you are able to watch live one of the observations then you can use:
sudo journalctl -f -u satnogs-client.servicenice catch… it seems that the script for FSK9K6 misses option --rf-gain. Would you mind to open a bug for it in Issues · librespacefoundation / SatNOGS / gr-satnogs · GitLab
I remember getting the same error but I didn’t investigated more as I was looking on sth else that time.
sudo journalctl -u satnogs-client.service | grep rror -A 2 -B 2
Oct 05 18:08:33 satnogs-uhf bash[715]: linux; GNU C++ version 6.2.0 20161010; Boost_106100; UHD_003.009.005-0-unknown
Oct 05 18:08:33 satnogs-uhf bash[715]: Usage: satnogs_fsk9600_g3ruh_ax25.py: [options]
Oct 05 18:08:33 satnogs-uhf bash[715]: satnogs_fsk9600_g3ruh_ax25.py: error: no such option: --rf-gain
Oct 05 19:45:05 satnogs-uhf bash[715]: linux; GNU C++ version 6.2.0 20161010; Boost_106100; UHD_003.009.005-0-unknown
Oct 05 19:45:05 satnogs-uhf bash[715]: Usage: satnogs_fsk9600_g3ruh_ax25.py: [options]
Oct 05 19:45:05 satnogs-uhf bash[715]: satnogs_fsk9600_g3ruh_ax25.py: error: no such option: --rf-gain
1 Like
Done, bug opened.
Finally journalctl allows you to filter logs with some time parameters… you need to check this in its manual.
Tried the above with: sudo journalctl -u satnogs-client.service --since=2017-10-05
However the log now only goes back to 1600 local, 0800z. Just over 4 hours worth of logging…
I guess you have defined a different rx gain with an environment variable right?
Indeed the fsk9k6 right now doesn’t support this… it will be fixed soon. Until then, as you have setup your rpi manually and not with the rasbian image, I suggest remove this environment variable and go to gr-satnogs directory and change the gain (watch out to be the rx one) in gr-satnogs/python/hw-settings.py file. After changing the file, you will need to go to gr-satnogs/build and run sudo make install, this will build and install gr-satnogs with your change.
When bug is fixed, return to gr-satnogs repo/directory run git checkout . to remove your change and then run the commands to download and build the new version.
Great! Thanks!
Yes, have defined gain for both.
At this stage UHF is 32.8 which is the default in hw-settings. VHF is 20.7. I’ll have to remake gr-satnogs there.
I’ve got ADSL issues at the moment because some nasty scum cut the Telco’s copper cable to my area.
Being on limited mobile (cell) broadband, I’m trying to refrain from downloading too much, hence still using my image. I think when the ADSL is back, I’ll retry the newer Raspbian image, now there’s been a few fixes.