Hello friends
For a few days I have been trying to configure client 2.0 with a Raspberry PI 3 and an RSP1 without luck. When executing journalctl -f -u satnogs-client.service I get the image error and the station appears offline. Can anybody help me?
Thanks and 73
EA4GSX
Please post the support info for your setup. sudo satnogs-setup -> Advanced -> Support
Hi Miguel,
import distutils.version [...] ValueError: bad marshal data (unknown type code)
This error indicates an issue with one or more compiled Python modules (pyc files) on your station, see also this SO question.
It might be related to the recent change from Python2.7 to Python3 for satnogs-client. PEP 552, implemented in CPython with release Python 3.7, added 4 bytes to the header of the Python pyc / bytecode files.
A similar issue describing this problem providing extensive links to related issues: home-assistant/supervisor#1415
Removing the affected (or more) compiled Python modules might solve this problem:
sudo find /var/lib/satnogs/lib -name '*.pyc' -delete
sudo find /usr/lib/python3 -name '*.pyc' -delete
Sincerely,
kerel
Thanks for the reply Kerel
I’ll check it this afternoon
73 de Miguel
Please also make sure that you have installed the soapysdr module for the SDR Play. To check if Soapy finds the SDRPlay module just run SoapySDRUtil --info
Where is located SoapySDRUtil? When I tried to run it, pi didn’t find it
sudo apt-get install soapysdr-tools
I also wanted to try with an sdrplay RSP1… Does that mean I don’t have the sdrplay module?
Lib Version: v0.6.1-4+b4
API Version: v0.6.0
ABI Version: v0.6
Install root: /usr
Search path: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.6
Search path: /usr/local/lib/arm-linux-gnueabihf/SoapySDR/modules0.6
Search path: /usr/local/lib/SoapySDR/modules0.6
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.6/libHackRFSupport.so
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.6/libLMS7Support.so
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.6/libRedPitaya.so
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.6/libairspySupport.so
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.6/libaudioSupport.so
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.6/libbladeRFSupport.so
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.6/libosmosdrSupport.so
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.6/libremoteSupport.so
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.6/librtlsdrSupport.so
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.6/libuhdSupport.so
Loading modules… done
Available factories…airspy, audio, bladerf, hackrf, lime, null, osmosdr, redpitaya, remote, rtlsdr, uhd,
Yeap. You need to install it manually, cause the driver library is closed source. Follow the procedure from https://github.com/pothosware/SoapySDRPlay/wiki and make sure that the installation path matches the path that Soapy on your machine searches for modules.
I don’t really know wich point or points from that link should I follow…
Soapy is already installed, don’t it?
Thanks
Soapy is already installed yes. For each device family soapy has a module that has to be installed. For the devices with open drivers everything is installed in the SatNOGS image. This is not true for the SDRPlay because it ships with a closed source driver. You have to compile and install the soapy module for the SDRPlay yourself.
The problem with python persists 
Also be warned - SoapySDRPlay uses somewhat unconventional gain settings, and setting any gain at all will result in a heap of attenuation being added. See this issue here: https://github.com/pothosware/SoapySDRPlay/issues/60
Because the latest SatNOGS updates don’t allow for the user to set these different gain parameters separately, it means that the default ‘gain distribution’ (and I use this term extremely loosely) in SoapySDR is used. This gain distribution basically takes the number you give it, and ‘fills up the gain buckets’ in whatever order the SDR module presents them. This can result in seriously bad gain settings on devices like the Airspy and SDR Play.
Yes, this is in part the fault of the SDR module authors not implementing gain distribution algorithms. Some of the modules have issues and/or PRs open to at least partially fix things. However it’s also partly the fault of the Soapy developers for possibly not realising that their gain distribution algorithm made basically no sense in the first place. Given how different some of these SDRs are, a ‘one-size-fits all’ solution is probably a bit idealistic.
Until either the upstream Soapy modules are changed to deal with gain distribution, or SatNOGS provides a way to set individual gains, then any SDR which more than one gain parameter is going to result in degraded performance, or a non-functional setup. This applies to the Airspy, SDRPlay, and probably other SDRs too. As the RTLSDRs only have one gain setting exposed (though realistically there should be 3 exposed, but librtlsdr doesn’t do this), it will work OK.
Just for info, here are the settings we used while testing the SDRplay RSPduo a few weeks ago:
export SATNOGS_SOAPY_RX_DEVICE="driver=sdrplay,serial=180603B532"
export SATNOGS_RX_SAMP_RATE=2000000
export SATNOGS_RX_BANDWIDTH=600000
export SATNOGS_RF_GAIN=34
export SATNOGS_ANTENNA="Tuner 1 50 ohm"
The results were very good!
So I’m wondering what the gain distribution algorithm did in that case?
I also note that those observations are missing all the usual observation metadata, so were these not captured using gr-satnogs?
They were captured using satnogs-client d9ff0e85 and gr-satnogs ba9e0e6 but the metadata reporting was broken at the time of testing c.f. issue 361.