PiAware 5.0

Weird, my Mlat seems to be running.

Schermafbeelding 2021-03-11 om 20.09.15

But I am not able to view my SkyAware.

dump1090 error

That is mentioned in the release notes in the first post in the official announcement thread. Apparently it is expected and normal

Successfully RE-IMAGED

(1) Stn 5252 - RPi Model 2 / Piaware SD card image v 5.0

1.1 - Down loaded and wrote following image to microSD card
http://piaware.flightcdn.com/piaware-sd-card-5.0.img.zip

1.2 - Followed instructions here
How to Install and Configure Piaware 5.0 SD card image - Quickstart Guide

 

(2) Stn 6396 - OrangePiPC / Armbian Buster

1.1 - Down loaded and wrote following image to microSD card
https://redirect.armbian.com/orangepipc/Buster_current

1.2 - Followed instructions here
[Package Install] How to Install and Configure Piaware on Raspberry Pi OS Image / RPi

 

(3) Stn 76000 - RPi Model 4 / 64-bit Raspberry Pi OS

1.1 - Down loaded and wrote following image to microSD card
https://downloads.raspberrypi.org/raspios_arm64/images/raspios_arm64-2020-08-24/2020-08-20-raspios-buster-arm64.zip

1.2 - Build & Installed piaware and dump1090-fa using following bash scripts

PIAWARE

sudo bash -c "$(wget -O - https://raw.githubusercontent.com/abcd567a/piaware-64bit-raspbian/main/build-and-install-piaware.sh)" 

NOTE: Please be patient. This will take very long time, as the script first installs build tools & dependency packages, and after that downloads source code & builds piaware from source code.

 

DUMP1090-FA

sudo bash -c "$(wget -O - https://raw.githubusercontent.com/abcd567a/piaware-64bit-raspbian/main/build-and-install-dump1090.sh)"  

NOTE: Please be patient. This will take very long time, as the script first installs build tools & dependency packages, and after that downloads source code & builds dump1090-fa from source code.

 

dump1090-fa

 

dump978-fa

Will be intresting to see how it effects the AirSpy receivers CPU usage and if we have to change settings

Can I just check…Is this used after cancelling the disable-mod command suggested earlier?

Many thanks

1 Like

Also any solution for graphs1090?

Thanks

Tried to update dump 1090. In the log it says:


So it seems it is running but in Skyaware I don’t see anything

The order doesn’t matter … you can re-enable dump1090-fa and fix it up.

The above fixup should also fix that i suppose?
Though i’m not sure what your exact issue is …
Try rerunning the graphs1090 setup as well see if that helps.
If you still have issues post in the graphs1090 thread?

You’re not being precise … which page is showing what?
Is /dump1090-fa working?
Is /skyaware working?

Many thanks for all your help with this. All working again now including graphs1090

Much appreciated

I didn’t notice this until I saw @NigelRichardson’s post, but mine is weird too, from the time I updated. I have re-run the install script & it didn’t seem to make a difference.

edit: never mind - it came back after I re-ran the lighty-enable-mod command

thanks, that worked for me too…

Hello,

I am trying to update to PiAware 5.0, but I’m running in some trouble.

  1. First I checked the “My ADS-B” page to start the update from there. For all my receivers I get the message “Sending commands to your device is not available because the feature is disabled locally on your device.”.
  2. I ran
    sudo piaware-config allow-auto-updates yes
    sudo piaware-config allow-manual-updates yes
    and I’m getting back that the values were set to “yes” in both cases. I checked again the stats page, but nothing changed.
  3. I tried piaware-config, but I’m getting back the following

warning: /etc/piaware.conf: failed to read config file: couldn’t open “/etc/piaware.conf”: permission denied

I tried instead sudo piaware-config -showall to see if something changed after step 2, but the two values are still set to “no”

What can I do in this regard? I assume that, unless I manage to change the configuration file, I can’t use the sudo apt-get update / sudo apt-get dist-upgrade to manually upgrade the piaware version. Currently I am using wiedehopf’s version of dump1090-fa with piaware and other similar feeders (by the way, thanks, wiedehopf, for your bundle install, it works great!).

Can you try restarting piaware after setting those piaware-config options with sudo?

sudo piaware-config allow-auto-updates yes
sudo piaware-config allow-manual-updates yes
sudo systemctl restart piaware

Sorry for not being accurate
Neither of them

Are you running tar1090?
If so just rerun the install script for that the issue (if it’s the commone one) should fix itself.

@eric1tran that worked, thanks. Sorry for the long post :slight_smile:
Now I am seeing the update commands on both my receivers, but it doesn’t seem to work. I tried not once, but three times. The log says that the commands are sent to the receiver, and the update is requested, but nothing happens after. I think I will let it until morning, now that the automatic updates were turned on, hopefully it will update by itself.

LE: I am getting this output from the log

[2021-03-11 23:23 EET] performing manual update, action: piaware
[2021-03-11 23:23 EET] child process 8846 exited with status EXIT 1
[2021-03-11 23:23 EET] update request complete
[2021-03-11 23:23 EET] *** running command ‘/usr/lib/piaware/helpers/run-apt-get update’ and logging output
[2021-03-11 23:23 EET] skipping action piaware
[2021-03-11 23:23 EET] run-apt-get(8846): Automatic updates not available for OS pi24-raspbian:10 (Raspbian GNU/Linux 10 (buster))
[2021-03-11 23:23 EET] manual update (user-initiated via their flightaware control page) requested by adept server

To avoid all this hasstle I upgraded by re-imaging the microSD csrds of all 3 Pi’s.

Re-imaging Made Easy

 

I had no issues by running sudo apt-get update, sudo apt-get upgrade. I did have a message about the dump1090 configuration file. I chose ‘Y’ to install the package maintainer’s version.

Lots of people will use the stats page to trigger the updates.
That doesn’t prompt obviously as it’s just a button so the version modified by tar1090 was kept around. The file not being updated produced a duplication of the /data definition for port 8080 which lighttpd errored on.