[OUTDATED] How to Install Piaware v 3.7.2 on Ubuntu 18.04 (Bionic) & Ubuntu 19.04 (Disco) amd64 / Intel PC

Yeah buster is in the dev branch i think.

But i wouldn’t expect any difference … if it works, it works.

This looks like it’s just that the bionic build rules didn’t get updated when I added dump978/faup978 support to piaware_builder (bionic isn’t “officially” supported, usually it doesn’t get tested). I’ll fix that up for 3.8.0.

3 Likes

Thanks obj,

Since I am not currently receiving 978 traffic I did a quick switch back to 1090 to make sure the stretch build didn’t break anything. All indications both local and online are good for the Ubuntu (Bionic) machine using PiAware 3.7.2 as stretch.

I thoroughly enjoyed troubleshooting this today and learning more about the software!

Thanks,

-Dan

Check the actual messages. For me, even if the indicator was green, the MLAT wasn’t working correctly, had some errors. That’s why I had to switch to the dev branch and that worked for me.

Hi SoNic67,

All areas are good. Some areas update almost immediately. The message count, hourly graph, and nearest stations status update takes a while. I learned not to check it too fast and wait 5-10 minutes for every area to settle down. I just looked again very closely at the MLAT update count, and it is increasing.

I did notice that the green MLAT box will show on and the text will display “Multilateration (MLAT): Supported / Enabled” even though MLAT is disabled for the single RTL UAT 978 device. MLAT is in fact off and you will not see the “(synchronized with xx nearby receivers)” part since MLAT is off.

The online gear icon for configure is more correctly labeled like below making it clear that MLAT indications are only for Mode-S.
Mode S Multilateration (MLAT)

Thanks for the backup though, and bringing that up will probably help others when checking their status changes.

Here’s one thing I did just learn after a closer look.

When switching a single RTL device back from 978 to 1090 I did this:

-Changed /etc/default/dump1090-fa setting to ENABLED=yes
-Changed /etc/default/dump978-fa setting to ENABLED=no

While that does in fact change the running decoder, it does NOT stop piaware from trying to connect to the other version of dump-fa which is of course not running. I noticed this by entries in the log showing piaware while running 1090 attempting to contact 978 like below. Notice the dump978 and port 30978 references.

Dec 23 20:41:02 Acer-722 piaware[999]: no ADS-B data program seen listening on port 30978 for 71 seconds, next check in 60s
Dec 23 20:41:18 Acer-722 piaware[999]: 820 msgs recv'd from dump1090-fa (24 in last 5m); 820 msgs sent to FlightAware
Dec 23 20:41:18 Acer-722 piaware[999]: 0 msgs recv'd from dump978 (0 in last 5m); 0 msgs sent to FlightAware
Dec 23 20:42:02 Acer-722 piaware[999]: no ADS-B data program seen listening on port 30978 for 131 seconds, next check in 60s
Dec 23 20:43:02 Acer-722 piaware[999]: no ADS-B data program seen listening on port 30978 for 191 seconds, next check in 60s

The solution is when changing single RTL between 1090 and 978 you must also edit this file:

dan@Acer-722:/etc$ sudo cat piaware.conf

feeder-id xxxx-edit-xxxx...
receiver-type       rtlsdr  # rtlsdr for 1090 or none to disable 1090
uat-receiver-type   none    # sdr for 978 or none to disable 978

-Dan

1 Like

@MC130E

Got it. I’m more of a manually edit the file kind of person, so I will continue to edit /etc/piaware.conf as described below with my reminder remarks about rtlsdr vs sdr naming conventions.

dan@Acer-722:/etc$ sudo cat piaware.conf

feeder-id xxxx-edit-xxxx...
receiver-type       rtlsdr  # rtlsdr for 1090 or none to disable 1090
uat-receiver-type   none    # sdr for 978 or none to disable 978

However, I no longer need to toggle the ENABLED=yes/no status in the other files. I now see it is safe to leave both set to yes and just did a quick test to prove both enabled works properly.

Thanks for making me notice that part!

-Dan

1 Like

Why don’t you just map the Ubuntu build targets to the debian build target code?

That way you don’t have duplicate code that gets stale.

Because, historically, there have been differences between distributions that were simplest to express by having an override directory per distribution. Unofficial Ubuntu support was tacked on using the existing mechanism. The real issue here is not how the packaging is structured, it is that the unofficial builds get no testing. If they’re not tested, they’ll silently break until actually used.

Well, for the moment the debian builds seem to be working for Ubuntu, that’s why i was proposing it.
Anyhow it doesn’t matter i guess :slight_smile:

piaware ver 3.8~dev on OrangePiPC / Armbian Buster (./sensible-build.sh buster)

pi@orangepipc:~$ uname -a
Linux orangepipc 5.3.9-sunxi #19.11.3 SMP Mon Nov 18 18:49:43 CET 2019 armv7l GNU/Linux


pi@orangepipc:~$ apt-cache policy piaware
piaware:
  Installed: 3.8.0~dev
  Candidate: 3.8.0~dev

.

2 Likes

Ubuntu was derived from Debian, so that’s no wonder it woks almost the same.
Who cares? I am one example :innocent:

I couldn’t make Debian work on my laptop, due to lack of support for the network (Ethernet and WiFi). Ubuntu had some Broadcom drivers out of the box. Those are proprietary (closed-source) drivers, kind of old and buggy… sometimes the WiFi network connection would just disappear.
So in the end I have bought from eBay the Intel “Centrino” WiFi module for that laptop, and that one is supported better, with integral (open-source?) drivers, way more stable.
Not sure if that Centrino WiFi chipset would be natively supported in Debian, because they don’t include any kind of proprietary drivers.

Since I have configured the laptop with Ubuntu I have stayed that way.

Hi all,

It looks like my statement above is incorrect and toggling ENABLED status is probably required.

Last night I left the test machine running a single RTL on 1090 as shown below. This morning it was offline with dump-978-fa running. I suspect that overnight after a short period of no coverage piaware restarted and then attempted to use the other enabled receiver (dump978-fa). This then led to the misconfiguration of dump978-fa running, faup1090 not running, and the 1090 mlat-client attempting to connect to the dump1090-fa ports. That’s an interesting mix up!

So, I will be toggling the ENABLED=yes/no status from now on and see if that handles periods of no reception.

For SoNic67, This might be related to the “MLAT errors” you reported previously because of the way it appears in the log.

Full details below.

-Dan

Single RTL on 1090 configuration running all night

dan@Acer-722:~$ sudo cat /etc/piaware.conf

feeder-id  xxxx-edit-xxxx
receiver-type             rtlsdr  #rtlsdr for 1090 or none to disable 1090
uat-receiver-type         none    #sdr for 978 or none to disable 978


dan@Acer-722:~$ cat /etc/default/dump1090-fa

dan@Acer-722:~$ cat /etc/default/dump1090-fa
# dump1090-fa configuration
# dump1090-fa won't automatically start unless ENABLED=yes
ENABLED=yes  ...and other required options below that


dan@Acer-722:~$ cat /etc/default/dump978-fa

# dump978-fa configuration
# dump978-fa won't automatically start unless ENABLED=yes
ENABLED=yes  ...and other required options below that

This morning offline. Piaware and 1090 mlat client running. dump1090-fa NOT running but top shows that dump978-fa is incorrectly running.

dan@Acer-722:~$ sudo piaware-status
PiAware master process (piaware) is running with pid 1018.
PiAware ADS-B client (faup1090) is not running.
PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)
PiAware mlat client (fa-mlat-client) is running with pid 1110.
Local ADS-B receiver (dump1090) is not running.

no program appears to be listening for ES 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.

Log shows 1090 mlat-client errors below because it is trying to connect to dump1090-fa ports which is not running (however dump978-fa is running on its different ports).

dan@Acer-722:/etc/default$ tail /var/log/piaware.log
Dec 24 08:27:03 Acer-722 piaware[1018]: mlat-client(1110): Connection to localhost:30005 lost: [Errno 111] Connection refused
Dec 24 08:27:03 Acer-722 piaware[1018]: mlat-client(1110): Reconnecting in 30.0 seconds
Dec 24 08:27:03 Acer-722 piaware[1018]: mlat-client(1110): Beast-format results connection with 127.0.0.1:30104: [Errno 111] Connection refused
Dec 24 08:27:34 Acer-722 piaware[1018]: mlat-client(1110): Connection to localhost:30005 lost: [Errno 111] Connection refused
Dec 24 08:27:34 Acer-722 piaware[1018]: mlat-client(1110): Reconnecting in 30.0 seconds
Dec 24 08:27:34 Acer-722 piaware[1018]: mlat-client(1110): Beast-format results connection with 127.0.0.1:30104: [Errno 111] Connection refused
Dec 24 08:27:38 Acer-722 piaware[1018]: no ADS-B data program seen listening on port 30005 for 310 seconds, next check in 60s
Dec 24 08:28:04 Acer-722 piaware[1018]: mlat-client(1110): Connection to localhost:30005 lost: [Errno 111] Connection refused
Dec 24 08:28:04 Acer-722 piaware[1018]: mlat-client(1110): Reconnecting in 30.0 seconds
Dec 24 08:28:04 Acer-722 piaware[1018]: mlat-client(1110): Beast-format results connection with 127.0.0.1:30104: [Errno 111] Connection refused

Like I said above the dev version 3.8.0 solved for me all those errors in MLAT 1090MHz.

Now, for UAT it makes no sense to have MLAT enabled, since there is no version of UAT without the GPS positions transmitted.
MLAT was (is?) necessary only for the legacy Mode S, preceding the ADS-B 1090MHz with GPS data.

However, at least in US, starting with 1st January 2020, MLAT should be technically dead even on 1090MHz:

For me, from almost 3000 planes per day, only 32 were MLAT yesterday.

dump978-fa on Debian 10 (Buster) amd64

(1) ver 3.7.2 - Fails

abcd@debian10:~$ uname -a
Linux debian10 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

abcd@debian10:~$ apt-cache policy dump978-fa
dump978-fa:
  Installed: 3.7.2
  Candidate: 3.7.2
  Version table:
 *** 3.7.2 100
        100 /var/lib/dpkg/status



abcd@debian10:~$ sudo journalctl -eu dump978-fa 

Dec 25 16:44:52 debian10 systemd[1]: Stopped dump978 ADS-B UAT receiver.
Dec 25 16:44:52 debian10 systemd[1]: Started dump978 ADS-B UAT receiver.
Dec 25 16:44:52 debian10 dump978-fa[6284]: raw-port: listening for connections on 0.0.0.0:30978
Dec 25 16:44:52 debian10 dump978-fa[6284]: raw-port: listening for connections on [::]:30978
Dec 25 16:44:52 debian10 dump978-fa[6284]: json-port: listening for connections on 0.0.0.0:30979
Dec 25 16:44:52 debian10 dump978-fa[6284]: json-port: listening for connections on [::]:30979
Dec 25 16:44:53 debian10 dump978-fa[6284]: Detached kernel driver
Dec 25 16:44:54 debian10 dump978-fa[6284]: Found Rafael Micro R820T tuner
Dec 25 16:44:55 debian10 dump978-fa[6284]: Reattached kernel driver
Dec 25 16:44:55 debian10 dump978-fa[6284]: usb_claim_interface error -6
Dec 25 16:44:55 debian10 dump978-fa[6284]: Detached kernel driver
Dec 25 16:44:56 debian10 dump978-fa[6284]: Found Rafael Micro R820T tuner
Dec 25 16:44:56 debian10 dump978-fa[6284]: Exact sample rate is: 2083333.135571 Hz
Dec 25 16:44:57 debian10 dump978-fa[6284]: [R82XX] PLL not locked!
Dec 25 16:44:57 debian10 dump978-fa[6284]: SoapySDR: using maximum manual gain 49.6 dB
Dec 25 16:44:57 debian10 dump978-fa[6284]: SoapySDR: using stream setting buffsize=262144
Dec 25 16:44:57 debian10 dump978-fa[6284]: [::]:30978: accepted a connection from [::1]:43786
Dec 25 16:44:57 debian10 dump978-fa[6284]: Allocating 15 zero-copy buffers
Dec 25 16:45:03 debian10 dump978-fa[6284]: Message source reports error: TIMEOUT
Dec 25 16:45:05 debian10 dump978-fa[6284]: Reattached kernel driver
Dec 25 16:45:05 debian10 dump978-fa[6284]: Abnormal exit
Dec 25 16:45:05 debian10 systemd[1]: dump978-fa.service: Main process exited, code=exited, status=1/FAILURE
Dec 25 16:45:05 debian10 systemd[1]: dump978-fa.service: Failed with result 'exit-code'.



(2) ver 3.8.0~dev - Fails

abcd@debian10:~$ uname -a
Linux debian10 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

abcd@debian10:~$ apt-cache policy dump978-fa
dump978-fa:
  Installed: 3.8.0~dev
  Candidate: 3.8.0~dev
  Version table:
 *** 3.8.0~dev 100
        100 /var/lib/dpkg/status



abcd@debian10:~$ sudo journalctl -eu dump978-fa 

Dec 25 17:04:17 debian10 systemd[1]: dump978-fa.service: Main process exited, code=exited, status=1/FAILURE
Dec 25 17:04:17 debian10 systemd[1]: dump978-fa.service: Failed with result 'exit-code'.
Dec 25 17:04:47 debian10 systemd[1]: dump978-fa.service: Service RestartSec=30s expired, scheduling restart.
Dec 25 17:04:47 debian10 systemd[1]: dump978-fa.service: Scheduled restart job, restart counter is at 2.
Dec 25 17:04:47 debian10 systemd[1]: Stopped dump978 ADS-B UAT receiver.
Dec 25 17:04:47 debian10 systemd[1]: Started dump978 ADS-B UAT receiver.
Dec 25 17:04:47 debian10 dump978-fa[11533]: raw-port: listening for connections on 0.0.0.0:30978
Dec 25 17:04:47 debian10 dump978-fa[11533]: raw-port: listening for connections on [::]:30978
Dec 25 17:04:47 debian10 dump978-fa[11533]: json-port: listening for connections on 0.0.0.0:30979
Dec 25 17:04:47 debian10 dump978-fa[11533]: json-port: listening for connections on [::]:30979
Dec 25 17:04:48 debian10 dump978-fa[11533]: Found Rafael Micro R820T tuner
Dec 25 17:04:49 debian10 dump978-fa[11533]: usb_claim_interface error -6
Dec 25 17:04:50 debian10 dump978-fa[11533]: Found Rafael Micro R820T tuner
Dec 25 17:04:51 debian10 dump978-fa[11533]: Exact sample rate is: 2083333.135571 Hz
Dec 25 17:04:51 debian10 dump978-fa[11533]: [R82XX] PLL not locked!
Dec 25 17:04:51 debian10 dump978-fa[11533]: SoapySDR: using maximum manual gain 49.6 dB
Dec 25 17:04:51 debian10 dump978-fa[11533]: SoapySDR: using stream setting buffsize=262144
Dec 25 17:04:51 debian10 dump978-fa[11533]: Allocating 15 zero-copy buffers
Dec 25 17:04:55 debian10 dump978-fa[11533]: [::]:30978: accepted a connection from [::1]:44282
Dec 25 17:04:57 debian10 dump978-fa[11533]: Message source reports error: TIMEOUT
Dec 25 17:04:59 debian10 dump978-fa[11533]: Abnormal exit
Dec 25 17:04:59 debian10 systemd[1]: dump978-fa.service: Main process exited, code=exited, status=1/FAILURE
Dec 25 17:04:59 debian10 systemd[1]: dump978-fa.service: Failed with result 'exit-code'.
1 Like

This might be a USB problem due to the virtual machine.
Also you are already using another receiver.
Try if it works with dump1090-fa stopped.

I have already tried this.
The dongle for dump1090-mutability (EB_VERSION) was working OK as I could see planes on map and piaware logs reported regularly receiving messages from it & sending to Flightaware.

I did following:

  1. Stopped dump1090-mutability and dump978-fa
  2. Unplugged the dongle being used by dump978-fa
  3. Changed device serial in /etc/default/dump978-fa to that of dongle used by dump1090-mutability.
  4. Restarted dump978-fa
  5. Checked dump978-fa status, Failure… (It starts, stays good for about 30 seconds, then crashes)

Could still be an issue with soapy-sdr and it’s interaction with the virtual machine.

I’m pretty sure i’ve used dump978-fa fine on my amd64 laptop.
(well it wouldn’t receive anything and i can’t test that because i’m in Europe, but it was running)

The soapysdr version would also be interesting, didn’t you downgrade that at some point?
apt show soapysdr-module-rtlsdr
this shows me version 0.6

May be the climate difference between Europe & Canada caused this :wink: :slightly_smiling_face:

I got exactly same results when I installed dump978-fa (ver 3.7.2 & ver 3.8.0~dev) on Armbian Buster / OrangePIPC.

Can you test 3.7.1, or do you know that works?

maybe i’ll plug a receiver into my server laptop real quick and give it a whirl.