[OUTDATED] How-to Feed Plane Plotter Site directly from Raspberry Pi

FlightAware ADS-B Flight Tracking
21

Nope didn’t work :frowning: still the same error.

I just copied and overwrite coaa.h to the ppup folder.

Here is the log:
gcc -O2 -g -Wall -W pkg-config --cflags librtlsdr -c ppup1090.c
gcc -O2 -g -Wall -W pkg-config --cflags librtlsdr -c anet.c
gcc -O2 -g -Wall -W pkg-config --cflags librtlsdr -c interactive.c
gcc -O2 -g -Wall -W pkg-config --cflags librtlsdr -c mode_ac.c
gcc -O2 -g -Wall -W pkg-config --cflags librtlsdr -c mode_s.c
gcc -O2 -g -Wall -W pkg-config --cflags librtlsdr -c net_io.c
gcc -g -o ppup1090 ppup1090.o anet.o interactive.o mode_ac.o mode_s.o net_io.o coaa1090.obj pkg-config --libs librtlsdr -lpthread -lm

pi@piaware:~/ppup $ ./ppup1090
Error 0xFFFFFFFE initialising uploader

22

Can you show the (regno and authcode redacted) output of:

cat coaa.h

Or you can just check yourself if the contents look correct.

I’m not sure what else it might be but that file seems like the most likely culprit.

23

This is the inside of coaa.h (I changed my real numbers to ‘x’)

//coaa.h configuration file for John Leo Navarro 2019-03-12 15:35:49
#define USER_REGNO xxx
#define USER_AUTHCODE xxxxxxxxx
#define USER_LATITUDE xxxxxxxxx
#define USER_LONGITUDE xxxxxxxxxx

24

Yeah i’m trying to reproduce the error but the only way i find to do that is to have bad data it coaa.h

For example if the #define USER_REGNO is only 3 digits, i get the same error.
Maybe the file they sent you is just faulty?

To double check that, can you try with the following in coaa.h:

#define USER_REGNO 234333
#define USER_AUTHCODE 23443543543
#define USER_LATITUDE 50.0
#define USER_LONGITUDE 10.0

It will not really allow you to upload data but it is just for testing.
(The application will start without error for me.)
To recompile you can use this command:

make -f makeppup1090 -B
1 Like
25

Your Test Code Works!!! hahahaha guess your right, its a problem on my coaa.h, not my fault though since they (COAA) are the one who created my coaa.h file :rofl:

I might request a new one tho, thank you for your help!

3 Likes
26

Remember you have to wait one minute to see output or upload.

27

An alternate (and better) method to start ppup1090 at boot is to create ppup1090.service file and enable it, so that ppup1090 is started by systemd instead of rc.local.

This method has following advantages:

  1. It makes starting of ppup1090 to wait till dump1090-fa, or dump1090-mutability starts.
  2. The user can control & monitor ppup1090 by systemctl commands.

The systemd method given below completely replaces following item of Post #1:
“(3) Make ppup1090 to auto-start at boot”

NOTE:
If you have already implemented rc.local startup of Post #1, and want to switch to systemd startup given below, first disable the rc.local startup by following steps:

(1) Open file rc.local to edit

sudo nano /etc/rc.local

(2) From the file opened, delete following line:

/home/pi/ppup/ppup-maint.sh &

(3) Save (Ctrl+o) and Close (Ctrl+x)

(4) Reboot RPi
sudo reboot

.

STEP BY STEP METHOD FOR STARTUP BY SYSTEMD

1 - Create system user ppup1090 which will start the service automatically at boot.

sudo useradd --system ppup1090

.

2 - Create a blank file ppup1090.service in folder /lib/systemd/system/ppup1090.service

sudo nano /lib/systemd/system/ppup1090.service

.

3 - Copy-paste following code in this blank file

Note-1: following 2 versions of code are identical, except for the line starting with After=

Note-2: Noted that systemd-journal continously runs & generates plane upload log. To overcome this and reduce cpu & memory usage, I have added --quiet at end of the line ExecStart=/home/pi/ppup/ppup1090.

`
.

IF USING DUMP1090-FA

Applies to:

  • Piaware SD Card image (which has dump1090-fa pre-installed).
  • Raspbian image with dump1090-fa package install.
# planeplotter uploader service for systemd
# create in /lib/systemd/system/
# then install in /etc/systemd/system/default.target.wants/ 
# by command: sudo systemctl enable ppup1090.service

[Unit]
Description=PlanePlotter Raspberry Pi uploader
Wants=network-online.target
After=dump1090-fa.service network-online.target time-sync.target

[Service]
User=ppup1090
RuntimeDirectory=ppup
ExecStart=/home/pi/ppup/ppup1090 --quiet
ExecReload=/bin/kill -HUP $MAINPID
Type=simple
Restart=on-failure
RestartSec=30
# exit code 4 means login failed
# exit code 6 means startup failed
RestartPreventExitStatus=4 6

[Install]
WantedBy=default.target

Save (Ctrl+o) and close (Ctrl+x)

.

IF USING DUMP1090-MUTABILITY

Applies to:

  • Raspbian image with dump1090-mutability ver 1.15~dev package install
  • PI24 image (which has dump1090-mutability ver 1.14 pre-installed)
# planeplotter uploader service for systemd
# create in /lib/systemd/system/
# then install in /etc/systemd/system/default.target.wants/ 
# by command: sudo systemctl enable ppup1090.service

[Unit]
Description=PlanePlotter Raspberry Pi uploader
Wants=network-online.target
After=dump1090-mutability.service network-online.target time-sync.target

[Service]
User=ppup1090
RuntimeDirectory=ppup
ExecStart=/home/pi/ppup/ppup1090 --quiet
ExecReload=/bin/kill -HUP $MAINPID
Type=simple
Restart=on-failure
RestartSec=30
# exit code 4 means login failed
# exit code 6 means startup failed
RestartPreventExitStatus=4 6

[Install]
WantedBy=default.target

Save (Ctrl+o) and close (Ctrl+x)

.

4 - Enable service by following command

sudo systemctl enable ppup1090.service  

sudo systemctl restart ppup1090

.

5 - Check status after few minutes

pi@raspberrypi:~ $ sudo systemctl status ppup1090
● ppup1090.service - PlanePlotter Raspberry Pi uploader
   Loaded: loaded (/lib/systemd/system/ppup1090.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2019-03-17 04:36:59 EDT; 5min ago
 Main PID: 860 (ppup1090)
   CGroup: /system.slice/ppup1090.service
           └─860 /home/pi/ppup/ppup1090 --quiet

Mar 17 04:36:59 raspberrypi systemd[1]: Started PlanePlotter Raspberry Pi uploader.

.

6 - Commands to control & monitor

sudo systemctl restart ppup1090   

sudo systemctl stop ppup1090   

sudo systemctl status ppup1090

.

3 Likes
FA and PlanePlotter
28

Thanks for this great posting; it sure helped me get everything running, feeding both FA and Planeplotter. I am using piaware 3.7.1, dump1090-fa and dump978-fa, 2 dongles, and the systemd start method. Works great after boot. Except for one problem. I know this is an old thread but maybe someone can help.

Periodically, every few days, or several times a day, something happens and dump1090 gets an error talking to the dongle (I believe). Piaware seems to recover by restarting dump1090-fa and faup1090 and all is well for FA. (yes, this may indicate a different problem that should not be happening anyway. Could be power related with 2 dongles, but I am using a current official Pi power supply, and a Pi2b.)

The problem is that when dump1090-fa restarts, it breaks the connection to ppup1090. ppup1090 continues to run, but is not really talking to the PlanePlotter servers any more. Manually restarting ppup1090 seems to restore the connections and all is well.

Is there a good way to restart ppup1090 (after a short delay) when dump1090-fa is restarted, using systemd methods? Or better to just make a script to start dump1090-fa, sleep, then start ppup1090, and call that in the dump1090-fa.service file instead of starting dump1090 and ppup1090 alone, each in their own service files?

For reference, here is the syslog when the restarts and ppup1090 failure occurs:

May 24 16:02:01 piaware CRON[13913]: (root) CMD (bash graphs1090.sh 6h >/dev/null 2>&1)
May 24 16:03:01 piaware CRON[14097]: (root) CMD (bash graphs1090.sh 24h >/dev/null 2>&1)
May 24 16:03:14 piaware dump1090-fa[8117]: cb transfer status: 1, canceling...
May 24 16:03:14 piaware dump1090-fa[8117]: rtlsdr: rtlsdr_read_async returned unexpectedly, probably lost the USB device, bailing out
May 24 16:03:14 piaware dump1090-fa[8117]: Fri May 24 16:03:14 2019 EDT  Waiting for receive thread termination
May 24 16:03:14 piaware dump1090-fa[8117]: Reattaching kernel driver failed!
May 24 16:03:14 piaware dump1090-fa[8117]: Fri May 24 16:03:14 2019 EDT  Abnormal exit.
May 24 16:03:14 piaware kernel: [102376.436831] dvb_usb_rtl28xxu 1-1.4:1.0: chip type detection failed -71
May 24 16:03:14 piaware kernel: [102376.436885] dvb_usb_rtl28xxu: probe of 1-1.4:1.0 failed with error -71
May 24 16:03:14 piaware rc.local[495]: Fri May 24 16:03:14 2019 Lost connection to localhost:30005
May 24 16:03:14 piaware systemd[1]: dump1090-fa.service: Main process exited, code=exited, status=1/FAILURE
May 24 16:03:14 piaware rc.local[495]: Fri May 24 16:03:14 2019 Reconnecting in 30.0 seconds
May 24 16:03:14 piaware rc.local[495]: Fri May 24 16:03:14 2019 Beast-format results connection with ::1:30104: connection lost
May 24 16:03:14 piaware systemd[1]: dump1090-fa.service: Unit entered failed state.
May 24 16:03:14 piaware systemd[1]: dump1090-fa.service: Failed with result 'exit-code'.
May 24 16:03:15 piaware kernel: [102376.586948] usb 1-1.4: USB disconnect, device number 9
May 24 16:03:15 piaware kernel: [102376.883371] usb 1-1.4: new high-speed USB device number 10 using dwc_otg
May 24 16:03:15 piaware kernel: [102377.025337] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=2832, bcdDevice= 1.00
May 24 16:03:15 piaware kernel: [102377.025356] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
May 24 16:03:15 piaware kernel: [102377.025364] usb 1-1.4: Product: RTL2832UFA
May 24 16:03:15 piaware kernel: [102377.025372] usb 1-1.4: Manufacturer: Realtek
May 24 16:03:15 piaware kernel: [102377.025379] usb 1-1.4: SerialNumber: 00001090
May 24 16:03:15 piaware kernel: [102377.034201] usb 1-1.4: dvb_usb_v2: found a 'Realtek RTL2832U reference design' in warm state
May 24 16:03:15 piaware kernel: [102377.088939] usb 1-1.4: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
May 24 16:03:15 piaware kernel: [102377.088984] dvbdev: DVB: registering new adapter (Realtek RTL2832U reference design)
May 24 16:03:15 piaware kernel: [102377.098407] i2c i2c-3: Added multiplexed i2c bus 4
May 24 16:03:15 piaware kernel: [102377.098425] rtl2832 3-0010: Realtek RTL2832 successfully attached
May 24 16:03:15 piaware kernel: [102377.098539] usb 1-1.4: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
May 24 16:03:15 piaware kernel: [102377.099763] r820t 4-001a: creating new instance
May 24 16:03:15 piaware kernel: [102377.111261] r820t 4-001a: Rafael Micro r820t successfully identified
29

Are you sure dump1090-fa starts again?

That shouldn’t be too hard.
Are you using the while loop (ppup-maint.sh) described at the start of this thread to start ppup1090?

Then you can do this hack, open /lib/systemd/system/dump1090-fa.service in an editor:

sudo nano /lib/systemd/system/dump1090-fa.service

Change this part:

[Service]
User=dump1090
RuntimeDirectory=dump1090-fa

Remove the “User=” line and add the “ExecStartPre” line so it looks like below:

[Service]
ExecStartPre=-/usr/bin/pkill ppup1090                                                                                             
RuntimeDirectory=dump1090-fa

Now everytime dump1090-fa starts it will terminate ppup1090.
This also makes dump1090 run as root.
But as ppup1090 is running as root already i don’t really see any problem with that.
I suppose you could also make ppup1090 run as user dump1090 as well for pkill to work.

Anyway if this problem started with having a second dongle then it is very likely your power supply to the USB receivers is inadequate.

30

Yes, dump1090-fa seems to restart with no problems.

I am using the systemd unit file method to start ppup1090, as shown in the posts just about ours here. So there is no infinite while loop running to restart it if killed. I’ll try that method next if needed, thanks for that.

I may have found a way to do it in the unit file (from my very limited knowledge and study of systemd unit files!). I added PartOf=dump1090-fa.service to the ppup1090.service unit file, which seems to force ppup to restart when dump restarts. Will wait to see if that works if/when dump1090 gets in trouble!

# planeplotter uploader service for systemd
# create in /lib/systemd/system/
# then install in /etc/systemd/system/default.target.wants/
# by command: sudo systemctl enable ppup1090.service

[Unit]
Description=PlanePlotter Raspberry Pi uploader
Wants=network-online.target
After=dump1090-fa.service network-online.target time-sync.target
PartOf=dump1090-fa.service

[Service]
User=ppup1090
RuntimeDirectory=ppup
ExecStart=/home/pi/ppup/ppup1090 --quiet --net-pp-ipaddr 192.168.1.149
ExecReload=/bin/kill -HUP $MAINPID
Type=simple
Restart=on-failure
RestartSec=30
# exit code 4 means login failed
# exit code 6 means startup failed
RestartPreventExitStatus=4 6

[Install]
WantedBy=default.target

I will also try a powered USB hub to help with possible power supply issues. This does seem to happen more when the ambient temp in my attic where the Pi lives goes up.

31

Yeah it should already restart automatically once it exits.
(But maybe the programming is bad and it doesn’t realize it’s lost the connection)

Maybe this is the problem.

When the problem occurs again make sure to check the log for that unit file:
sudo journalctl -eu ppup1090

And check if it stopped and didn’t restart.

Just assumed you were using the while loop script, with a systemd unit it’s actually easier.
Will have to remember that “PartOf”, seems handy.

32

Agree, ppup should restart on failure already. However, it does not appear to fail, or stop, or log any problem when this occurs, just keeps on like nothing happened. Then in an hour I get the email from PlanePlotter that I am no longer feeding :slight_smile: Maybe I should run ppup with logging, but that log gets out of control pretty quick and I don’t see any logging options (like error only). I needed a way to kick that oblivious process…

So I’m voting on bad programming in ppup1090, which seems to be unchanged and unmaintained for years. Might look at the code one day.

33

The source code for the core of it is not available, AFAIK (this is why I stopped maintaining it in my forks)

1 Like
34

I have two RPi3B installations, one running 24/7 at home and one for us in overseas locations when I am away. The original one (24/7 since April 2019) was operating on Raspbian Stretch, using Dump1090-mutability (installed through the ADS-B Receiver Project / J Prochazka), and feeding PlanePlotter through ppup1090 (installed in accordance with the instructions here), FR24, Plane Finder and 360 Radar.

The “mobile” RPi is built on Raspbian Buster, using Dump1090-fa (but without feeding FlightAware, installed through Wiedehopf) and again feeding PlanePlotter through ppup1090 (installed in accordance with the instructions here), FR24, Plane Finder and 360 Radar (albeit to their MLAT test server).

I decided to clone the latter SD card to update the home machine (I have retained and stored the original SD card for the moment). Updating the FR24 and Plane Finder feeds were pretty straightforward and they both now operate with the original machine no.1 sharing keys.

For PlanePlotter, I initially replaced my coaa.h file on the cloned SD card with that from the original, now stored SD card. Following a reboot PlanePlotter uploading immediately worked, but I observed that the PlanePlotter uploading was still showing as the sharecode from the no.2 (mobile) RPi. I concluded that I needed to recompile ppup1090 from source code. This was only possible by renaming the ppup folder as “ppup_old” and redoing steps 2.1 to 2.3, recopying the original coaa.h file to the “new” ppup folder and then repeating step 2.6.

This was a success, with my rebuilt home RPi now uploading with the correct sharecode. However, it begged the question, if one changes ANYTHING in one’s coaa.h file (e.g. lat & long coordinates for my “mobile” RPi, does one then have to recompile ppup1090 everytime?

Second question - the replacement SD card in the “home” RPi has been operating for 48 hours now and the PlanePlotter uploading has failed in the middle of the night both nights. Yet, the uploading to FR24 and Plane Finder have remained operational, as (of course) has Dump1090-fa. A reboot of the RPi (through SSH) has restored the PlanePlotter feed, but what could be causing ppup1090 to crash please? (I went for weeks, if not months, with no crashes using the earlier SD card).

Appreciate some opinions,
Ian

35

PlanePlotter uploader is a ridiculous way of doing things.

I wouldn’t be surprised if it just doesn’t work on Buster.
As you note, having to recompile to change the location doesn’t speak for this piece of software.

You have at least logs for the uploader?
Without even an error message, there is nothing to go on.
Even then, it’s not open source if i remember correctly, so probably no one here can help you.
You’ll have to take it up with PlanePlotter.

36

This was the case last time I checked (or at least I couldn’t find anyone who could tell me the license of the binary object file that gets linked, and I wasn’t about to reverse engineer it without knowing that)

37

I have had these not feeding Planeplotter alerts. First time I got one I went up to the attic to restart the RPi. When it happened again I just left it and found there had actually been no drop out so it was a false alarm. Changed the alert to 2 hours and haven’t been alerted since.

38

The file coaa.h received from planeplotter must be placed in the source-code folder before running the make command. This is important as the command make -f makeppup1090 copies all particulars of coaa.h into the binary ppup1090 during its compilation.

As all data of coaa.h is included in compiled binary ppup1090 , the file coaa.h is not used in running the ppup1090 binary. Any changes, or even deleting the file coaa.h will not affect the operation of ppup1090 as it will use only the user/station data contained within itself.

You can confirm this by deleting file coaa.h after executing command make -f makeppup1090, and then run ppup1090. It will run successfully with user data supplied to it before compilation.

39

Thanks. It is working fine on Buster, save the two overnight crashes. I will continue to monitor this.

I have also placed a similar post on the PlanePlotter forum too.

40

Thank you, that is very helpful and confirms my own thoughts.

Whilst not really a problem for static RPi’s (unless, like me, one wants to update the SD card OS), but more of an issue for RPi’s that are used in various locations, e.g. hotel rooms.

Anyway, my two are both correct now and ppup1090 has been recompiled in both instances.