ADS-B Receiver Project Setup Scripts

Fixed a PiAware version variable that was not changed which should solve this issue. I really need to work on consolidating these… Running the scripts again using the upgrade commands located in the first post and choosing to upgrade PiAware when asked should straighten things out by in fact installing PiAware 2.1-5-jessie and not simply reinstalling PiAware 2.1-5 as was happening before this fix.

A couple things to keep in mind when rerunning the scripts.
You can skip anything else you may have already installed when running through the setup again.
At this moment each successive run will report that PiAware has an upgrade available due to the fact the new 2.1-5-jessie package is still seen as 2.1-5 by the system when installed.

I made some changes to the script pertaining to how the mlatResultsFormat string was created fixing an issue with this setting being overwritten when PiAware was upgraded. At the time I did not take into account a clean installation of PiAware does not have this setting available to be cleaned. The problem is fixed now and pushed to the repository.

At this time in order to get the max range graphs to work you need to manually specify your feeders latitude and longitude in /etc/default/dump1090-mutability. Please refer to the wiki page found here for more detailed instructions: github.com/jprochazka/adsb-feed … ange-graph

Has CPU usage settled down at all over time?

@jprochazka Cracking good job! :laughing:

1 Understood.
3 My bad. I remember doing it before, but I’ve slept since. :blush:
4 CPU usage is fine, <25%. I believe FA is a bit overzealous and was picking up a spike during the boot up as it was too transcient to show on the graphs.

Phill

Test on brand new SD card, Pi2, 2015-11-21-raspbian-jessie-lite.img. Started Jan 5th 2016, 21:00 GMT.

First, I did essential RPi tasks:


~ $ sudo raspi-config

(expand FS, change pi password, set IE locale (en_IE.UTF-8 UTF-8), timezone Dublin, overclock to Pi2 setting)

Then:


sudo apt-get update
sudo apt-get upgrade
sudo apt-get install git
cd ~/
git clone https://github.com/jprochazka/adsb-feeder.git
cd ~/adsb-feeder
chmod +x install.sh
./install.sh

My choices were:


                              │                                                                            │
                              │   * Operating system updates will be applied.                              │
                              │                                                                            │
                              │ The following software will be installed:                                  │
                              │                                                                            │
                              │   * dump1090-mutability                                                    │
                              │   * FlightAware PiAware                                                    │
                              │   * ADS-B Feeder Project Web Portal                                        │


Installation took about 30 min without any obvious errors and I entered heywhatsthat ID during dump1090-mutability install.

Manually configured dump1090-mutability:


pi@raspberrypi:~/adsb-feeder $ sudo dpkg-reconfigure dump1090-mutability

update lat/long
gain -10
bind to interface: blank

Two main problems:
**1) dump1090-mutability did not start. ** Log reads:


pi@raspberrypi:~/adsb-feeder $ cat /var/log/dump1090-mutability.log
Tue Jan  5 21:11:58 2016 GMT  dump1090-mutability v1.15~dev starting up.
Using sample converter: UC8, integer/table path
Found 1 device(s):
0: , ▒, SN: ▒▒▒T (currently selected)
usb_open error -3
Please fix the device permissions, e.g. by installing the udev rules file rtl-sdr.rules
Error opening the RTLSDR device: Permission denied


I fixed this by doing:


pi@raspberrypi:~ $ lsusb
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

sudo nano /etc/udev/rules.d/rtl-sdr.rules

This file was blank (or non-existent). Added following line to it and saved:


SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", MODE:="0666” -

Then:


pi@raspberrypi:~ $ sudo service udev restart
pi@raspberrypi:~ $ sudo /etc/init.d/dump1090-mutability restart

Now dump1090-mutability starts fine and shows map with aircraft.

2) Piaware was not installed during script run
Manually did:


~ $ cd /adsb-feeder/build/piaware_builder
pi@raspberrypi:~/adsb-feeder/build/piaware_builder $ sudo dpkg -i piaware_2.1-5_armhf.deb
pi@raspberrypi:~/adsb-feeder/build/piaware_builder $ sudo /etc/init.d/piaware start


Remaining issue in /tmp/piaware.out:


01/05/2016 22:24:16 mlat(1376): Beast-format results connection with localhost:30104: [Errno 111] Connection refused

Fixed this by running:


$ sudo dpkg-reconfigure dump1090-mutability

and specifying:


Port for Beast-format input connections (0 disables): 
    │   
    │ 30104

Finally:


sudo /etc/init.d/piaware restart

Hope the above helps to straighten out remaining kinks.

  1. The start up issue is known about. Generally a reboot after setup solves the issue without the need to modify anything further. However I will be going through your process to see if I can close the issue related to this problem. Honestly I would rather dump1090 start up during the setup process rather than force a reboot. github.com/jprochazka/adsb-feeder/issues/13

the following error message occurred because PiAware was not installed by the scripts so was not able to configure PiAware to listen on port 30004 instead of 30104. The reason for PiAware to not installing is covered under the explanation for 2).

Beast-format results connection with localhost:30104: [Errno 111] Connection refused

This also brings up an issue I will be adding to the tracker…
The script was supposed to stop whenever an issue such as this was encountered.

  1. Just posted a temporary fix for this issue. Here is a run down of what was happening.

It relates to the issue I made light of in an earlier post where after installing 2.1-5-jessie the scripts will continue to show there is an upgrade for PiAware available.

There is a variable set at the top of the file bash/piaware.sh which can be changed whenever a newer version of PiAware is released. Going from 2.1.-4 to 2.1-5 worked great this way. However when 2.1-5-jessie was released fixing the certificate error which had been cropping up as of late a problem came in to play when changing to this tag. When built, 2.1-5-jessie retains the version number of the 2.1-5 not 2.1-5-jessie as expected. So when using the dpk -i which uses the CURRENTVERSION variable to identify the package just built it cannot find it because the package name for the newly built 2.1-5-jessie is in fact named piaware_2.1-5.deb not piaware_2.1-5-jessie.deb as I expected.

This was something I should have tested and did not due to time constraints and I apologize for that…

The old scripting looked like this.


CURRENTVERSION="2.1-5-jessie"
...
git checkout tags/v${CURRENTVERSION}
...
sudo dpkg -i $BUILDDIR/piaware_builder/piaware_${CURRENTVERSION}_*.deb

The temporary fix I put into place looks something like this.


CURRENTVERSION="2.1-5-jessie"
CURRENTVERSIONNAME="2.1-5"
...
git checkout tags/v${CURRENTVERSION}
...
sudo dpkg -i $BUILDDIR/piaware_builder/piaware_${CURRENTVERSIONNAME}_*.deb

Yes I think you are correct: as a test, I removed my previously created /etc/udev/rules.d/rtl-sdr.rules, rebooted and dump1090-mutability still starts fine without it. But if you want to consider creating this file during install, you need to match up the vendor and product ID’s with what is found in the output of lsusb command; in particular, the entry of the dongle.

Thanks for the explanation of issue 2) - makes sense :slight_smile:

Actually, I think you have it the wrong way round and this may still be an issue: Recent piaware (from 2.1-3) and fa-supplied dump1090 have standardised on port 30104 for mlat back-feed into dump1090. So piaware was installed correctly (albeit manually by me). It is dump1090-mutability that needs to be reconfigured to make it listen on 30104 instead of the previous default of 30004.

More info see here:
https://discussions.flightaware.com/ads-b-flight-tracking-f21/piaware-2-1-3-released-t36047.html
I think it is best to stick with the default port of 30104.

I went off their recommendations being that dump1090-mutability1.5~dev at least in my eyes constituted “using a different dump1090” being it is not what is ran on their stock PiAware image. I simply used their first recommendation listed which was to reconfigure PiAware. The reason initially was due to the fact it is easier to run a command than pick through a configuration file to replace a setting.

Keep in mind I am going to have to dig into the dump1090-mutability configuration here shortly in order to deal with the lat/lon max range graph issue. When I do I will be more than happy to come back and address this at that time if that is the way we should go.

That is unless anyone sees another reason to continue to allow dump1090 beast format connections on the original port 30004.

Maybe I will leave the decision to the user at that time from within the script…

What I need to do is make dump1090-mutability listen on both 30004 and 30104 by default. Currently that’s not possible, it needs a bit of work in the code.

The idea with 30104 is that 30004 is already used by a bunch of non-mlat-aware existing installs for Beast input, so the only thing that’s safe to send there is non-mlat data. Anything listening on 30104 is assumed to be mlat-aware. But something that is mlat-aware can listen on both (30004 for backwards compatibility, 30104 to accept mlat data)

Ok, thanks for the explanation and background! I guess both ports are valid and work well. I just don’t like to use old defaults :laughing:

Edit: did not see obj’s post just above while writing this.

That being said will work on setting 30104 in dump1090-mutability over changing PiAware’s setting.
Thanks for clearing this up for us obj.

still seems this error is cropping up in the pi-aware installation of the script …skipping… 6a883f4 jessie’s c_rehash doesn’t like multiple certificates per file ,split them and terminates the script at that point tried reinstalling twice with same result
script works fine from start to finnish if I leave pi-aware out of the install on Ubuntu 14.4

Now that you mention it, I also saw “jessie’s c_rehash doesn’t like multiple certificates per file ,split them” message during my install a few days ago but the script continued seemingly fine. It did build the piaware package but did not install it. A subsequent manual installation of the package went fine.

I’ll try a fresh rebuild, but that message is the GitHub commit message that Obj used when he fixed the issue, it wasn’t added to the install script. You all are on Raspberries, correct?

[quote=“dschaper”]

I’m on Raspberry Pi B+, with Jessie. My last install was on the 5th. I did not see the, “jessie’s c_rehash doesn’t like multiple certificates per file ,split them” message during the install though I did have to split the files.

Phill

[quote=“dschaper”]

no I was trying to install the script on Ubuntu 14.4 when getting ]jessie’s c_rehash doesn’t like multiple certificates per file ,split them .last line after this was end it did not continue

Yes, Pi2 model B with 2015-11-21-raspbian-jessie-lite.img

Okay, I’ll try to set up a virtual Ubuntu x86 and see what I can find, it looks like the current script runs okay with the Raspberries, just a cursory check doesn’t reveal any problems, the Jessie message is just the one from the GitHub commit as I suspected… I’ll do a deeper dive and see what comes up.

If you’re following along at home, the GitHub repository where I do most of my reports is at https://github.com/jprochazka/adsb-feeder/issues.

I’m running into problems installing PiAware on Ubuntu Trusty but the problem isn’t with JP’s script. It’s in the sensible-build.sh script which is flightaware’s script. I’ll open an issue with that repo and see what comes up. Bash -x locks up at the git log -1 --oneline section…

What happens if you run sensible-build directly from a shell?

(I wonder if the git pager is kicking in and confusing things)

Same lock, I posted a bash -x dump on GitHub.

Edit: It does appear to be related to the pager, the commit message isn’t completely displayed before the lockup.