I have an issue originating with an unstable clock but know this is probably hardware related. I’ll debug and figure out the offending hardware; that is not the purpose of this post.
When I encounter the unstable clock issue, I see in the logs that dump1090 stops sending to piaware and eventually piaware attempts to repair the system and restart dump1090 (which BTW a service restart does resolve the lack of sending). The problem however is that piaware is unable to locate the service if I’m interpreting the log message correctly, but the very next line is references ‘dump1090-mutabi’.
Feb 26 23:35:00 piaware piaware[522]: attempting to restart dump1090..
Feb 26 23:35:01 piaware piaware[522]: can't restart dump1090, no services that look like dump1090 found
Feb 26 23:35:11 piaware piaware[522]: ADS-B data program 'dump1090-mutabi' is listening on port 30005, so far so good
The question is why can’t piaware find the service? Manually, I’m able to restart dump1090-mutability.service via systemctl or the service command.
Related to permissions? (Don’t think so, but…?) #allow-auto-updates no # using default value
allow-manual-updates yes # value set at /boot/piaware-config.txt:4
My setup is via package installs: Piaware 3.3.0 and dump1090-mutability 1.15~dev on RPi2 v1.1 and using blue FA dongle (amp/filter).
I think you are correct. A quick test of some other systemd commands reveal more that don’t return results as I would have expected, e.g., is-enabled vs. is-failed vs. is-active.
Need some help …
Due to a SD-Card failure, I installed again piaware-sd-card-3.5.3.img on a new fresh 16 GB card. Everything is running (WLAN, access via ssh, etc.) except dump1090-fa will not start, only the spinning wheel is turning around …
Status reports as follows
+++
pi@MB08:~$ sudo piaware-status
PiAware master process (piaware) is running with pid 581.
PiAware ADS-B client (faup1090) is not running.
PiAware mlat client (fa-mlat-client) is not running.
Local ADS-B receiver (dump1090) is not running.
no program appears to be listening for connections on port 30005.
faup1090 is NOT connected to the ADS-B receiver.
piaware is connected to FlightAware.
got ‘couldn’t open socket: connection refused’
dump1090 is NOT producing data on localhost:30005.
(EDIT) First, my RasPiZero is connected to RTL2832U DVBT-Stick.
and here’s my output:
++++++++++
pi@MB08:~$ sudo apt-get install rtl-sdr
Reading package lists… Done
Building dependency tree
Reading state information… Done
rtl-sdr is already the newest version.
rtl-sdr set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
pi@MB08:~$ sudo killall dump1090-fa
dump1090-fa: no process found
pi@MB08:~$ sudo rtl_test -t
No supported devices found.
Sorry, the orange stick + filter is connected to my RasPi3; my Zero is connected to a RTL2832U R820T DVBT-Stick.
Your dongle connected to Pi Zero (MB08) is NOT working. Unplug it and then replug and reboot Pi. If this does not work, unplug it and replug in another USB port, and reboot Pi. Most likely this will fix connection issues.
If all this does not fix the problem, then most likely your Orange dongle is defective or DC power adaptor is bad.
.
.
The Orange Pro Stick is actually DVB-T (RTL2832U R820T) + Amplifier. The rtl_test -t will give identical output for both DVB-T and Orange Pro Stick, except that the serial # of DVB-T is 00000001 and that of Orange Pro Stick is 00001000.
.
Here is output generated by my Orange Pro Stick
sudo killall dump1090-fa
sudo rtl_test -t
Found 1 device(s):
0: Realtek, RTL2832U, SN: 00001000
Using device 0: Generic RTL2832U
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
Sampling at 2048000 S/s.
No E4000 tuner found, aborting.
If you have connected dongle to Pi Zero using a USB extender cable, then remove cable and plug the dongle directly into Pi Zero’s USB port. Often USB extender cable cause such problems.
So you have to use a microUSB to USB adapter cable. Well this one may be the cause of problem. If you have another such cable, try it, but first plugout Orange dongle from your Pi3, and plug into Pi Zero and reboot Pi Zero. This will determine if it is dongle or cable which is faulty.
Connection stick-to-PiZero is established via a short USB-USB cable and an USB-microUSB-Adapter.
The short USB cable wasn’t plugged in “deep enough” into the adapter, hahaha …
But I’m still wondering, why command “killall dump1090-fa” said “no dump1090-fa found” …
Thx again for your support – normally I put an eye on all connections first …
.
Glad to know that you found and fixed the problem.
.
.
The command “sudo killall dump1090-fa” kills all the running instances of dump1090-fa. As the dump1090-fa has already failed (due to missing dongle) and no more running, the command did not find any running instance of dump1090-fa, and gave output “dump1090-fa: no process found”. This output does NOT mean the software dump1090-fa is NOT installed on your Pi. It only tells that there is “currently no running instance of dump1090-fa”
When dongle is working and dump1090-fa is running, issuing this command will silently kills it and will NOT give any output. You can then check its success by command sudo systemctl status dump1090-fa -l
sudo systemctl status dump1090-fa -l
............
...........
#Last 3 lines of output are:
Caught SIGTERM, shutting down..
Waiting for receive thread termination
Normal exit.
.
.
To check if dump1090-fa is installed or not, use command apt-cache policy dump1090-fa
… now it works …
