SatNOGS Wiki - User contributions [en]

Software Defined Radio

2020-02-25T05:54:00Z

Satnogs4:

==Introduction==

SatNOGS can use a variety of SDRs. The most cost-effective solution is to use an RTL-SDR with a Raspberry Pi. More advanced SDRs can also be used, but they require more processing power than what a Raspberry Pi can offer.

==RTL-SDR: RTL2832U & R820T2-Based Software Defined Radios==
SatNOGS uses the RTL-SDR as the default signal receiver and tuner. The RTL-SDR is based on two chips -- the versatile [http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=35&Level=4&Conn=3&ProdID=257 RTL2832U chip] and the [https://rtl-sdr.com/wp-content/uploads/2013/04/R820T_datasheet-Non_R-20111130_unlocked.pdf R820T tuner]. The RTL-SDR is currently the cheapest, most common, and most performing solution available in terms of general sensitivity having a frequency range of 24 – 1766 MHz. A metal enclosure with SMA connector is preferred, along with a stable TCXO (low ppm). HF coverage is optional.

These RTL-SDR "dongles" are known to work with Raspberry Pi 2 or greater:

*[https://www.nooelec.com/store/sdr/sdr-receivers.html NooElec NESDR SMArt]
*[https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/ RTL-SDR Blog R820T2 RTL2832U]
*Full band UV HF RTL-SDR USB Tuner Receiver

 

===Using RTL-SDR.com V3 Dongle's Bias-T Power Supply===
The RTL-SDR.com V3 dongle has a built in software activated Bias-T voltage supply intended to be used for applications such as powering inline LNAs (Low Noise Amplifiers). There are several ways to turn on the voltage, but through initial testing (as of this writing, 17 Aug 2019) it seems that the following procedure works best.

The below relates to Raspberry Pi installs only. No testing has been performed on other systems as of yet.

''WARNING: Turning on the Bias-T with no LNA installed and a "shorted" style antenna (such as loops, egg-beaters, etc.) can damage the RTL-SDR.com V3 dongle. Never activate the bias-t with no LNA installed between the antenna and the SDR dongle.''

'''Requirements:'''

#Raspberry Pi running Raspbian Buster or newer (latest release of SatNogs image, [https://gitlab.com/librespacefoundation/satnogs/satnogs-pi-gen/-/tags 2019091100], is demonstrated to work)
#[https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/ RTL-SDR.com V3 SDR dongle]
#[https://www.rtl-sdr.com/rtl-sdr-blog-v-3-dongles-user-guide/ RTL-SDR.com Bias-T Software Switch] for linux systems
#LNA capable of being powered via feedline coax (note that some LNAs need modifications to be powered by the coax, and some cannot be powered by the coax at all. Check the specifications for your LNA prior to attempting to turn on the Bias-T power supply)

 

====Instructions for installing RTL-SDR.com Bias-T Software Switch====

#Log into your SatNogs station either directly or via SSH
#If your station does not have cmake installed (SatNogs Image 2019091100 does not), install cmake with <code>sudo apt install cmake</code>
#Clone the source for the Bias-T software switch with <code>git clone <nowiki>https://github.com/rtlsdrblog/rtl_biast</nowiki></code>
#<code>cd rtl_biast</code>
#<code>mkdir build</code>
#<code>cd build</code>
#<code>cmake ..</code> (if you get a <code>LibUSB 1.0 required to compile rtl-sdr</code> error here, then do <code>sudo apt install libusb-1.0-0-dev</code> prior to attempting <code>cmake ..</code> again)
#<code>make</code>

The software switch should now be installed in the "src" directory. If you <code>cd src</code>, you can turn on the bias-t with the command <code>./rtl_biast -b 1</code> and turn it off with <code>./rtl_biast -b 0</code>. Note that the developers of this switch have warned against attempting to <code>sudo make install</code> so that this command can be executed from ouside the src directory. Testing has shown this warning to be accurate, so don't plan on running these commands from anywhere but the src directory, or else be sure to use the full path.

Switching the Bias-T on should yield between 4.5V and 5.0V across the center conductor and shield of the coax. The voltage should rise almost instantly. When switched off, the voltage seems to decrease gradually, over 5 to 10 seconds.

====Instructions to activate the bias-t for SatNogs Observations automatically:====

#Log into your SatNogs station either directly or via SSH
#<code>sudo satnogs-setup</code>
#select <code>Advanced</code>
#for <code>Radio</code> -> <code>SATNOGS_DEV_ARGS</code>, enter <code>rtl=0,buffers=32,buflen=16384,bias=1</code> and select <code>Ok</code>. If you have multiple dongles, change <code>rtl=0</code> to the appropriate index.
#for <code>Radio</code> -><code>SATNOGS_RF_GAIN</code>, enter a low gain value supported by your RTL-SDR.com V3 dongle (entering <code>rtl_test</code> at the command line prior to starting <code>satnogs-setup</code> will give you all allowable values of RF gain) and select <code>Ok</code>
#for <code>Scripts</code> -><code>SATNOGS_POST_OBSERVATION_SCRIPT,</code> enter <code>/home/pi/rtl_biast/build/src/rtl_biast -b 0</code> and select <code>Ok</code>
#Select <code>Back</code>
#Select <code>Apply</code> (allow sytem to update and hit enter when prompted)
#Select <code>Back</code>

Your station is now set up to turn the Bias-T on for each scheduled observation (using the <code>SATNOGS_DEV_ARGS</code> string) and then turn it off at the conclusion of each observation (using the <code>SATNOGS_POST_OBSERVATION_SCRIPT</code>).

You should now schedule several observations to fine tune the <code>SATNOGS_RF_GAIN</code> value to get the best S/N performance for your station. Some have reported needing zero RF gain, others have reported low RF gain required (between 5 and 10 db), and others have said they see little benefit even with very high gain. Each station will be different.

==Advanced Software Defined Radios==
The following advanced SDRs are supported by SatNOGS. These may require more processing power than a Raspberry Pi 3b or 4 can offer.

*[https://www.ettus.com/product/category/USRP-Bus-Series USRP b200]
*[https://www.ettus.com/product/category/USRP-Networked-Series USRP2] (not compatible with the SatNOGS client on Raspberry Pi)
*[https://airspy.com/ Airspy] (not compatible with the SatNOGS client on Raspberry Pi)
*[https://greatscottgadgets.com/hackrf/ HackRF One] (not compatible with the SatNOGS client on Raspberry Pi)

==References==

*[https://www.rtl-sdr.com/rtlsdr4everyone-review-of-5-rtl-sdr-dongles/ Review of 5 RTL-SDR Dongles]
*[https://hackaday.com/2017/09/05/19-rtl-sdr-dongles-reviewed/ 19 RTL-SDR Dongles Reviewed]
*[https://www.rtl-sdr.com/review-airspy-vs-sdrplay-rsp-vs-hackrf/ Review: Airspy VS. SDRplay RSP VS. HackRF]

[[Category:Build]]
[[Category:Hardware]]
[[Category:Software]]

__NOEDITSECTION__

Troubleshooting Legacy

2020-02-24T11:33:42Z

Satnogs4: /* Blank or solid purple waterfall? */

==Client troubleshooting==

===Client not showing up on the network?===

*Check that you have ticked the "Is it operational?" checkbox on the groundstation page.
*Check your settings and ensure that the API token and station ID are correct. You can get these from your profile page on the SatNOGS network site. If you have accounts in both dev and prod, make sure you're using the token and station ID from the right environment.
*Check your SATNOGS_NETWORK_API_URL. It should point to https://network.satnogs.org/api/ (prod) or https://network-dev.satnogs.org/api/ (dev).
*Check your network connectivity. Can you ping network.satnogs.org or network-dev.satnogs.org? Try running <code>curl https://network.satnogs.org</code> or <code>curl https://network-dev.satnogs.org</code>.
*Check the logs for an error (<code>journalctl -f -u satnogs-client.service</code> or <code>less /var/log/supervisor/satnogs-error.log</code>) and post to our forums at https://community.libre.space

==="satnogsclient - ERROR - Cannot connect to socket 127.0.0.1:4533"===

The client is trying to connect to rotctld but is unable to.

*If you have a no-rotator setup, ensure that satnogs-client is configured as such; see the [[Raspberry Pi]] page for info on how to do this.
**These errors may continue to be reported until [https://gitlab.com/librespacefoundation/satnogs/satnogs-client/issues/340 issue #340] is resolved.

*If you do have a rotator, ensure that rotctld is running.

 

===Some uploads missing & Doppler-correction not working properly===
The station/client might have a clock offset. This causes a Doppler shift on the waterfall and some observations don't start because of a conflict between the time on the PC of the station and the time of the SatNOGS Network.

===Uploads (waterfall or audio) are missing for a past observation===
When using <code>satnogs-setup</code> for editing/updating the configuration of the station, the satnogs-client gets restarted. When this happens during an observation the observation will be aborted and no waterfall/audio/data files will be uploaded. Such observations should be voted as ''failed''.

The partial data from such observations is stored in <code>/tmp/.satnogs/data/</code>, look for files like <code>receiving_{satnogs|waterfall}_123456_2019-01-01T12-23-42.{out|dat}</code>. They can be manually removed.

==Signal troubleshooting==

===Blank or solid purple waterfall?===
At the first sign of trouble, put your station into testing mode. This way bad waterfalls do not get uploaded to the database.

*Make sure the RTLSDR gain is set correctly. If set too high, a blank waterfall can result. If set to low, same. Test a value between 7 and 15. Check your gain value is valid. Wrong values can result in blank waterfalls. For example '7.7.' will result in errors (and a blank waterfall - there is an extra '.' at the end). <code>journalctl -u satnogs-client.service</code> It might be a big file, but work through it and look for errors. <code>df -h</code> Ensure there is sufficient hard drive space. If temp files can not be created, the waterfall might be blank. Run <code>rtl_test</code> for about 30 seconds and make sure you can connect with the dongle and that there are no errors.

===Not receiving anything?===

*Make sure the satellite you are testing observations against is active and recently received by others on [https://network.satnogs.org our production network site]. If you click on a satellite name, a popup will appear and give you the option to click on "Past Observations". If everything in the past shows red, then the problem is likely with that satellite.

*SO-50 is a good satellite to use for testing as it is a strong FM voice signal assuming you have UHF capabilities. Schedule using "PE0SAT - Mode V/U FM Voice - 436.794 MHz". Here is an example to compare against: https://network.satnogs.org/observations/3334/

*ISS is a good test for VHF as the APRS digipeater is alive again (as of this writing; check [https://www.issfanclub.com/ issfanclub.com] for up-to-date information). When you schedule it, be sure to select the APRS downlink.

*If you're using an rtlsdr, check that it can be seen and is operating correctly by running rtl_test. Let it run for 30 seconds or so, then hit Ctrl-c to kill it:

<pre>
pi@raspberrypi:~ $ rtl_test
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
[R82XX] PLL not locked!
Sampling at 2048000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
^CSignal caught, exiting!

User cancel, exiting...
Samples per million lost (minimum): 0
</pre>

*You can also try a manual run of satnogs_fm_demod.py to make sure that works:

<pre>
$ cd /tmp
$ satnogs_fm_demod.py --rx-sdr-device=rtlsdr --rx-freq=444000000 --file-path=./audio-out.ogg --waterfall-file-path=./waterfall.dat
</pre>

Let it run for a minute or so. If everything is working, this should create an .ogg file and a .dat file of non-zero size (probably a few MB each).

===Observations seem off-frequency?===
[[File:Waterfall_3519_2017-04-24T04-48-48_resized.png|frame|Check your location!]]

*'''PPM drift''' While newer SDR devices are very good and stable, there still may be some PPM drift to compensate for if you notice that signals are consistently off center. The SATNOGS_PPM_ERROR setting in /etc/supervisord.d/satnogs.ini can be used to correct for this.
*'''Clock sync''' Make sure your clock is synced. Ensure ntp is configured and running (especially with the Raspberry Pi which lacks a real time clock)
*'''Wrong location''' If your signal seems to be on but drifts at the apex like in this image, check to make sure your Latitude, Longitude, and Elevation coordinates are set properly and in the right format.

===USB===
You can reset USB without having to reboot the system by running these commands:

echo “usb1” > /sys/bus/usb/drivers/usb/unbind
echo “usb1” > /sys/bus/usb/drivers/usb/bind

This can be placed in the satnogs_post_observation_script for automation.

===RF Noise===
If you notice a noise in the waterfall every time motors are spinning, you will need to:

*Twist each pair or the motor wire
*Add proper grounding
*Add capacitor to the DC input of drivers
*Wrap the motors wire with adhesive aluminum and then connect it to GND on driver side
*Add ferrites to motors wires

[[File:Rf noise.png|alt=RF Noise|left|thumb|400x400px|Too much RF Noise]]

[[Category:Operate]]
[[Category:Hardware]]
[[Category:Software]]

Troubleshooting Legacy

2020-02-24T11:30:11Z

Satnogs4: Document that removing 4533 port errors is as of yet unsolvable.

==Client troubleshooting==

===Client not showing up on the network?===

*Check that you have ticked the "Is it operational?" checkbox on the groundstation page.
*Check your settings and ensure that the API token and station ID are correct. You can get these from your profile page on the SatNOGS network site. If you have accounts in both dev and prod, make sure you're using the token and station ID from the right environment.
*Check your SATNOGS_NETWORK_API_URL. It should point to https://network.satnogs.org/api/ (prod) or https://network-dev.satnogs.org/api/ (dev).
*Check your network connectivity. Can you ping network.satnogs.org or network-dev.satnogs.org? Try running <code>curl https://network.satnogs.org</code> or <code>curl https://network-dev.satnogs.org</code>.
*Check the logs for an error (<code>journalctl -f -u satnogs-client.service</code> or <code>less /var/log/supervisor/satnogs-error.log</code>) and post to our forums at https://community.libre.space

==="satnogsclient - ERROR - Cannot connect to socket 127.0.0.1:4533"===

The client is trying to connect to rotctld but is unable to.

*If you have a no-rotator setup, ensure that satnogs-client is configured as such; see the [[Raspberry Pi]] page for info on how to do this.
**These errors may continue to be reported until [https://gitlab.com/librespacefoundation/satnogs/satnogs-client/issues/340 issue #340] is resolved.

*If you do have a rotator, ensure that rotctld is running.

 

===Some uploads missing & Doppler-correction not working properly===
The station/client might have a clock offset. This causes a Doppler shift on the waterfall and some observations don't start because of a conflict between the time on the PC of the station and the time of the SatNOGS Network.

===Uploads (waterfall or audio) are missing for a past observation===
When using <code>satnogs-setup</code> for editing/updating the configuration of the station, the satnogs-client gets restarted. When this happens during an observation the observation will be aborted and no waterfall/audio/data files will be uploaded. Such observations should be voted as ''failed''.

The partial data from such observations is stored in <code>/tmp/.satnogs/data/</code>, look for files like <code>receiving_{satnogs|waterfall}_123456_2019-01-01T12-23-42.{out|dat}</code>. They can be manually removed.

==Signal troubleshooting==

===Blank or solid purple waterfall?===
At the first sign of trouble, put your station into testing mode. This way bad waterfalls do not get uploaded to the database.

*Make sure the RTLSDR gain is set correctly. If set too high, a blank waterfall can result. If set to low, same. Test a value between 7 and 15. Check your gain value is valid. Wrong values can result in blank waterfalls. For for example '7.7.' will result in errors (and a blank waterfall - there is an extra '.' at the end). <code>journalctl -u satnogs-client.service</code> It might be a big file, but work through it and look for errors. <code>df -h</code> Ensure there is sufficient hard drive space. If temp files can not be created, the waterfall might be blank. Run <code>rtl_test</code> for about 30 seconds and make sure you can connect with the dongle and that there are no errors.

===Not receiving anything?===

*Make sure the satellite you are testing observations against is active and recently received by others on [https://network.satnogs.org our production network site]. If you click on a satellite name, a popup will appear and give you the option to click on "Past Observations". If everything in the past shows red, then the problem is likely with that satellite.

*SO-50 is a good satellite to use for testing as it is a strong FM voice signal assuming you have UHF capabilities. Schedule using "PE0SAT - Mode V/U FM Voice - 436.794 MHz". Here is an example to compare against: https://network.satnogs.org/observations/3334/

*ISS is a good test for VHF as the APRS digipeater is alive again (as of this writing; check [https://www.issfanclub.com/ issfanclub.com] for up-to-date information). When you schedule it, be sure to select the APRS downlink.

*If you're using an rtlsdr, check that it can be seen and is operating correctly by running rtl_test. Let it run for 30 seconds or so, then hit Ctrl-c to kill it:

<pre>
pi@raspberrypi:~ $ rtl_test
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
[R82XX] PLL not locked!
Sampling at 2048000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
^CSignal caught, exiting!

User cancel, exiting...
Samples per million lost (minimum): 0
</pre>

*You can also try a manual run of satnogs_fm_demod.py to make sure that works:

<pre>
$ cd /tmp
$ satnogs_fm_demod.py --rx-sdr-device=rtlsdr --rx-freq=444000000 --file-path=./audio-out.ogg --waterfall-file-path=./waterfall.dat
</pre>

Let it run for a minute or so. If everything is working, this should create an .ogg file and a .dat file of non-zero size (probably a few MB each).

===Observations seem off-frequency?===
[[File:Waterfall_3519_2017-04-24T04-48-48_resized.png|frame|Check your location!]]

*'''PPM drift''' While newer SDR devices are very good and stable, there still may be some PPM drift to compensate for if you notice that signals are consistently off center. The SATNOGS_PPM_ERROR setting in /etc/supervisord.d/satnogs.ini can be used to correct for this.
*'''Clock sync''' Make sure your clock is synced. Ensure ntp is configured and running (especially with the Raspberry Pi which lacks a real time clock)
*'''Wrong location''' If your signal seems to be on but drifts at the apex like in this image, check to make sure your Latitude, Longitude, and Elevation coordinates are set properly and in the right format.

===USB===
You can reset USB without having to reboot the system by running these commands:

echo “usb1” > /sys/bus/usb/drivers/usb/unbind
echo “usb1” > /sys/bus/usb/drivers/usb/bind

This can be placed in the satnogs_post_observation_script for automation.

===RF Noise===
If you notice a noise in the waterfall every time motors are spinning, you will need to:

*Twist each pair or the motor wire
*Add proper grounding
*Add capacitor to the DC input of drivers
*wrap the motors wire with adhesite aluminum and then connect it to GND on driver side
*add ferites to motors wires

[[File:Rf noise.png|alt=RF Noise|left|thumb|400x400px|Too much RF Noise]]

[[Category:Operate]]
[[Category:Hardware]]
[[Category:Software]]