Difference between revisions of "Troubleshooting"

From SatNOGS Wiki
(adding RF noise)
(Client troubleshooting: Add missing uploads due to clock offset)
Line 1: Line 1:
  
== Client troubleshooting ==
+
==Client troubleshooting==
  
=== Client not showing up on the network? ===
+
===Client not showing up on the network?===
  
* Check that you have ticked the "Is it operational?" checkbox on the groundstation page.
+
*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 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 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 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
+
*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" ===
+
==="satnogsclient - ERROR - Cannot connect to socket 127.0.0.1:4533"===
  
 
The client is trying to connect to rotctld but is unable to.
 
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 3]] page for info on how to do this.
+
*If you have a no-rotator setup, ensure that satnogs-client is configured as such; see the [[Raspberry Pi 3]] page for info on how to do this.
  
* If you do have a rotator, ensure that rotctld is running.
+
*If you do have a rotator, ensure that rotctld is running.
  
== Signal troubleshooting ==
+
<br />
  
=== Not receiving anything? ===
+
=== 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.
  
* 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.
+
==Signal troubleshooting==
  
* 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/
+
===Not receiving anything?===
  
* 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.
+
*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.
  
* 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:
+
*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>
 
<pre>
Line 51: Line 56:
 
</pre>
 
</pre>
  
* You can also try a manual run of satnogs_fm_demod.py to make sure that works:
+
*You can also try a manual run of satnogs_fm_demod.py to make sure that works:
  
 
<pre>
 
<pre>
Line 61: Line 66:
  
 
[[File:Waterfall_3519_2017-04-24T04-48-48_resized.png|frame|Check your location!]]
 
[[File:Waterfall_3519_2017-04-24T04-48-48_resized.png|frame|Check your location!]]
=== Observations seem off-frequency? ===
+
===Observations seem off-frequency?===
* '''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)
+
*'''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.
* '''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.
+
*'''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.
 +
 
 
[[File:Rf noise.png|alt=RF Noise|left|thumb|400x400px|Too much RF Noise]]
 
[[File:Rf noise.png|alt=RF Noise|left|thumb|400x400px|Too much RF Noise]]
  
=== RF Noise ===
+
===RF Noise===
 
If you notice a noise in the waterfall every time motors are spinning, you will need to:
 
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
+
*Twist each pair or the motor wire
* Add capacitor to the DC input of drivers
+
*Add proper grounding
* wrap the motors wire with adhesite aluminum and then connect it to GND on driver side
+
*Add capacitor to the DC input of drivers
* add ferites to motors wires
+
*wrap the motors wire with adhesite aluminum and then connect it to GND on driver side
 +
*add ferites to motors wires

Revision as of 09:08, 17 July 2019

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 curl https://network.satnogs.org or curl https://network-dev.satnogs.org.
  • Check the logs for an error (journalctl -f -u satnogs-client.service or less /var/log/supervisor/satnogs-error.log) 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 3 page for info on how to do this.
  • 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.

Signal troubleshooting

Not receiving anything?

  • Make sure the satellite you are testing observations against is active and recently received by others on 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 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:
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
  • You can also try a manual run of satnogs_fm_demod.py to make sure that works:
$ cd /tmp
$ satnogs_fm_demod.py --rx-sdr-device=rtlsdr --rx-freq=444000000 --file-path=./audio-out.ogg --waterfall-file-path=./waterfall.dat

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).

Check your location!

Observations seem off-frequency?

  • 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.
RF Noise
Too much RF Noise

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