Announcement

Collapse
No announcement yet.

Archived - Beta test MLAT software for Raspberry Pi

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • k5hmd
    replied
    I'm unable to get the map using ip_of_pi:8080 or ip_of_pi/dump1090. Do I need to enable it someway? Using 1.0.18-9.

    Suggestions?

    Thanks,
    Joe

    Leave a comment:


  • Oblivian
    replied
    Originally posted by Tayloss View Post
    Yes, everything was run as SUDO and have checked the /etc/system.d/system directory and can see that the fr24feed service already has root privilege..

    -rw-r--r-- 1 root root 621 Jan 19 10:39 fr24feed.service

    I did check the permissions before posting, but even as a normal user, it should have internet access on all ports and addresses..

    Does seems to be challenging since the upgrade..

    Thanks for your help tho..

    Chris
    I'd provide a server to manually check, but they differ by region being CDN front end.

    Sent from my XT1092 using Tapatalk

    Leave a comment:


  • Tayloss
    replied
    Originally posted by Oblivian View Post
    Just another quirk to add to the list.

    Assuming you ran all the bash scripts/install commands as sudo it may need the service command permission changed - *think* the command structure below is correct
    Yes, everything was run as SUDO and have checked the /etc/system.d/system directory and can see that the fr24feed service already has root privilege..

    -rw-r--r-- 1 root root 621 Jan 19 10:39 fr24feed.service

    I did check the permissions before posting, but even as a normal user, it should have internet access on all ports and addresses..

    Does seems to be challenging since the upgrade..

    Thanks for your help tho..

    Chris

    Leave a comment:


  • Oblivian
    replied
    Originally posted by Tayloss View Post
    Hi All,

    I've suffered the same issue as others in that my FR24FEED program stopped and caused issues, so have purged and reinstalled by following the instructions posted earlier this week, however, I have a slightly different issue related to running the program as a service. If i use SUDO SYSTEMCTL START FR24FEED, I get the following in the log file and it never connection to the server

    Code:
    2018-01-21 23:46:39 | [main][i]FR24 Feeder/Decoder
    2018-01-21 23:46:39 | [main][i]Version: 1.0.19-5/generic
    2018-01-21 23:46:39 | [main][i]Built on Jan 19 2018 10:38:52 (T201801191038/Linux/static_arm)
    2018-01-21 23:46:39 | [main][i]Copyright 2012-2018 Flightradar24 AB
    2018-01-21 23:46:39 | [main][i]
    2018-01-21 23:46:39 | [main][i]DNS mode: PING
    2018-01-21 23:46:39 | [main][i]Automatic updates are ENABLED
    2018-01-21 23:46:39 | [httpd][i]Server started, listening on 0.0.0.0:8754
    2018-01-21 23:46:39 | [main][i]Reader thread started
    2018-01-21 23:46:39 | [main][i]MLAT data feed started
    2018-01-21 23:46:39 | [master][i]Starting processing thread
    2018-01-21 23:46:39 | [mlat][i]Waiting for MLAT configuration
    2018-01-21 23:46:39 | [reader][i]Initializing reader
    2018-01-21 23:46:39 | [reader][i]Connecting to AVR-TCP receiver via (avr-tcp://127.0.0.1:30002)
    2018-01-21 23:46:39 | [reader][i]Connected to the receiver, configuring
    2018-01-21 23:46:39 | [reader][i]Configured, processing messages
    2018-01-21 23:46:40 | [reader][w]Setting new UTC offset: 0!
    2018-01-21 23:46:40 | [time][i]Synchronizing time via NTP
    2018-01-21 23:46:40 | [time][e]Failed to synchronize time
    2018-01-21 23:46:40 | [main][w]Failed to synchronize time, waiting 5 seconds
    2018-01-21 23:46:45 | [time][i]Synchronizing time via NTP
    2018-01-21 23:46:46 | [time][e]Failed to synchronize time
    2018-01-21 23:46:46 | [main][w]Failed to synchronize time, waiting 5 seconds
    2018-01-21 23:46:51 | [time][i]Synchronizing time via NTP
    2018-01-21 23:46:51 | [time][e]Failed to synchronize time
    2018-01-21 23:46:51 | [main][w]Failed to synchronize time, waiting 5 seconds
    Running FR24SERVICE shows:-

    [ ok ] FR24 Feeder/Decoder Process: running.
    [ ok ] FR24 Stats Timestamp: 2018-01-22 00:04:15.
    [FAIL] FR24 Link: unknown ... failed!
    [ ok ] Receiver: connected (1188 MSGS/0 SYNC).
    [FAIL] FR24 MLAT: not running ... failed!

    BUT if I run in logging mode, it appears fine:-
    Code:
    2018-01-22 00:05:31 | [main][i]FR24 Feeder/Decoder
    2018-01-22 00:05:31 | [main][i]Version: 1.0.19-5/generic
    2018-01-22 00:05:31 | [main][i]Built on Jan 19 2018 10:38:52 (T201801191038/Linux/static_arm)
    2018-01-22 00:05:31 | [main][i]Copyright 2012-2018 Flightradar24 AB
    2018-01-22 00:05:31 | [main][i]
    2018-01-22 00:05:31 | [main][i]DNS mode: PING
    2018-01-22 00:05:31 | [main][i]Automatic updates are ENABLED
    2018-01-22 00:05:31 | [httpd][i]Server started, listening on 0.0.0.0:8754
    2018-01-22 00:05:31 | [master][i]Starting processing thread
    2018-01-22 00:05:31 | [main][i]Reader thread started
    2018-01-22 00:05:31 | [reader][i]Initializing reader
    2018-01-22 00:05:31 | [reader][i]Connecting to AVR-TCP receiver via (avr-tcp://127.0.0.1:30002)
    2018-01-22 00:05:31 | [reader][i]Connected to the receiver, configuring
    2018-01-22 00:05:31 | [reader][i]Configured, processing messages
    2018-01-22 00:05:31 | [main][i]MLAT data feed started
    2018-01-22 00:05:31 | [mlat][i]Waiting for MLAT configuration
    2018-01-22 00:05:32 | [reader][w]Setting new UTC offset: 0!
    2018-01-22 00:05:32 | [time][i]Synchronizing time via NTP
    2018-01-22 00:05:51 | [time][i]Time synchronized correctly, offset -0.0004 seconds
    2018-01-22 00:05:51 | [main][i]Feed Network client started
    2018-01-22 00:05:51 | [feed][i]Downloading configuration
    2018-01-22 00:05:51 | [feed][c]Interval: 5s
    2018-01-22 00:05:51 | [feed][c]Latitude: 50.8478
    2018-01-22 00:05:51 | [feed][c]Longitude: -1.1523
    2018-01-22 00:05:51 | [feed][c]GND: YES
    2018-01-22 00:05:51 | [feed][c]NonADSB: YES
    2018-01-22 00:05:51 | [feed][c]Timestamps: optional
    2018-01-22 00:05:51 | [feed][c]Max range AIR: 350.0nm
    2018-01-22 00:05:51 | [feed][c]Max range GND: 100.0nm
    2018-01-22 00:05:51 | [feed][i]defined 5 servers
    2018-01-22 00:05:51 | [stats][i]Stats thread started
    2018-01-22 00:05:51 | [feed][n]EGVF14@83.140.21.85:8099/UDP
    2018-01-22 00:05:51 | [feed][n]connecting
    2018-01-22 00:05:51 | [feed][n]connected via UDP (fd 9)
    2018-01-22 00:05:51 | [feed][n]working
    2018-01-22 00:05:51 | [mlat][i]MLAT configuration received, service ENABLED
    2018-01-22 00:05:51 | [mlat][i]Starting MLAT with preconfigured position: 50.85,-1.15, 8.0
    2018-01-22 00:05:51 | [mlat][i]MLAT bandwidth reduction active, level 1
    2018-01-22 00:05:51 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
    2018-01-22 00:05:51 | [mlat][i]Registering MLAT station
    2018-01-22 00:05:51 | [mlat][i]Registering MLAT station: SUCCESS
    2018-01-22 00:05:52 | [feed][i]sent 1,0 AC
    2018-01-22 00:05:53 | [mlat][i]Received ADS-B time references AC:
    2018-01-22 00:05:53 | [mlat][i] 4CA96C
    2018-01-22 00:05:53 | [mlat][i]Pinging the server
    2018-01-22 00:05:53 | [mlat][i]Stats 11373197/11373197
    2018-01-22 00:05:57 | [feed][i]sent 4,0 AC
    2018-01-22 00:06:02 | [feed][i]sent 3,0 AC
    I'm at a loss as to what could cause this issue as I thought they'd be using the same method?

    The system doesn't have a firewall, and I can ping all of the NTP servers, so am really confused...

    Thanks,
    Chris
    Just another quirk to add to the list.

    Assuming you ran all the bash scripts/install commands as sudo it may need the service command permission changed - *think* the command structure below is correct
    FR24feed Not auto-starting on reboot
    - Not sure why/not enough info provided to pinpoint cause or fix
    - poss owner of run service string
    sudo chown root:root /etc/systemd/system/fr24feed.service

    Leave a comment:


  • Tayloss
    replied
    Raspberry PI - Stopped, Fixed, and broken again...

    Hi All,

    I've suffered the same issue as others in that my FR24FEED program stopped and caused issues, so have purged and reinstalled by following the instructions posted earlier this week, however, I have a slightly different issue related to running the program as a service. If i use SUDO SYSTEMCTL START FR24FEED, I get the following in the log file and it never connection to the server

    Code:
    2018-01-21 23:46:39 | [main][i]FR24 Feeder/Decoder
    2018-01-21 23:46:39 | [main][i]Version: 1.0.19-5/generic
    2018-01-21 23:46:39 | [main][i]Built on Jan 19 2018 10:38:52 (T201801191038/Linux/static_arm)
    2018-01-21 23:46:39 | [main][i]Copyright 2012-2018 Flightradar24 AB
    2018-01-21 23:46:39 | [main][i]
    2018-01-21 23:46:39 | [main][i]DNS mode: PING
    2018-01-21 23:46:39 | [main][i]Automatic updates are ENABLED
    2018-01-21 23:46:39 | [httpd][i]Server started, listening on 0.0.0.0:8754
    2018-01-21 23:46:39 | [main][i]Reader thread started
    2018-01-21 23:46:39 | [main][i]MLAT data feed started
    2018-01-21 23:46:39 | [master][i]Starting processing thread
    2018-01-21 23:46:39 | [mlat][i]Waiting for MLAT configuration
    2018-01-21 23:46:39 | [reader][i]Initializing reader
    2018-01-21 23:46:39 | [reader][i]Connecting to AVR-TCP receiver via (avr-tcp://127.0.0.1:30002)
    2018-01-21 23:46:39 | [reader][i]Connected to the receiver, configuring
    2018-01-21 23:46:39 | [reader][i]Configured, processing messages
    2018-01-21 23:46:40 | [reader][w]Setting new UTC offset: 0!
    2018-01-21 23:46:40 | [time][i]Synchronizing time via NTP
    2018-01-21 23:46:40 | [time][e]Failed to synchronize time
    2018-01-21 23:46:40 | [main][w]Failed to synchronize time, waiting 5 seconds
    2018-01-21 23:46:45 | [time][i]Synchronizing time via NTP
    2018-01-21 23:46:46 | [time][e]Failed to synchronize time
    2018-01-21 23:46:46 | [main][w]Failed to synchronize time, waiting 5 seconds
    2018-01-21 23:46:51 | [time][i]Synchronizing time via NTP
    2018-01-21 23:46:51 | [time][e]Failed to synchronize time
    2018-01-21 23:46:51 | [main][w]Failed to synchronize time, waiting 5 seconds
    Running FR24SERVICE shows:-

    [ ok ] FR24 Feeder/Decoder Process: running.
    [ ok ] FR24 Stats Timestamp: 2018-01-22 00:04:15.
    [FAIL] FR24 Link: unknown ... failed!
    [ ok ] Receiver: connected (1188 MSGS/0 SYNC).
    [FAIL] FR24 MLAT: not running ... failed!

    BUT if I run in logging mode, it appears fine:-
    Code:
    2018-01-22 00:05:31 | [main][i]FR24 Feeder/Decoder
    2018-01-22 00:05:31 | [main][i]Version: 1.0.19-5/generic
    2018-01-22 00:05:31 | [main][i]Built on Jan 19 2018 10:38:52 (T201801191038/Linux/static_arm)
    2018-01-22 00:05:31 | [main][i]Copyright 2012-2018 Flightradar24 AB
    2018-01-22 00:05:31 | [main][i]
    2018-01-22 00:05:31 | [main][i]DNS mode: PING
    2018-01-22 00:05:31 | [main][i]Automatic updates are ENABLED
    2018-01-22 00:05:31 | [httpd][i]Server started, listening on 0.0.0.0:8754
    2018-01-22 00:05:31 | [master][i]Starting processing thread
    2018-01-22 00:05:31 | [main][i]Reader thread started
    2018-01-22 00:05:31 | [reader][i]Initializing reader
    2018-01-22 00:05:31 | [reader][i]Connecting to AVR-TCP receiver via (avr-tcp://127.0.0.1:30002)
    2018-01-22 00:05:31 | [reader][i]Connected to the receiver, configuring
    2018-01-22 00:05:31 | [reader][i]Configured, processing messages
    2018-01-22 00:05:31 | [main][i]MLAT data feed started
    2018-01-22 00:05:31 | [mlat][i]Waiting for MLAT configuration
    2018-01-22 00:05:32 | [reader][w]Setting new UTC offset: 0!
    2018-01-22 00:05:32 | [time][i]Synchronizing time via NTP
    2018-01-22 00:05:51 | [time][i]Time synchronized correctly, offset -0.0004 seconds
    2018-01-22 00:05:51 | [main][i]Feed Network client started
    2018-01-22 00:05:51 | [feed][i]Downloading configuration
    2018-01-22 00:05:51 | [feed][c]Interval: 5s
    2018-01-22 00:05:51 | [feed][c]Latitude: 50.8478
    2018-01-22 00:05:51 | [feed][c]Longitude: -1.1523
    2018-01-22 00:05:51 | [feed][c]GND: YES
    2018-01-22 00:05:51 | [feed][c]NonADSB: YES
    2018-01-22 00:05:51 | [feed][c]Timestamps: optional
    2018-01-22 00:05:51 | [feed][c]Max range AIR: 350.0nm
    2018-01-22 00:05:51 | [feed][c]Max range GND: 100.0nm
    2018-01-22 00:05:51 | [feed][i]defined 5 servers
    2018-01-22 00:05:51 | [stats][i]Stats thread started
    2018-01-22 00:05:51 | [feed][n]EGVF14@83.140.21.85:8099/UDP
    2018-01-22 00:05:51 | [feed][n]connecting
    2018-01-22 00:05:51 | [feed][n]connected via UDP (fd 9)
    2018-01-22 00:05:51 | [feed][n]working
    2018-01-22 00:05:51 | [mlat][i]MLAT configuration received, service ENABLED
    2018-01-22 00:05:51 | [mlat][i]Starting MLAT with preconfigured position: 50.85,-1.15, 8.0
    2018-01-22 00:05:51 | [mlat][i]MLAT bandwidth reduction active, level 1
    2018-01-22 00:05:51 | [mlat][i]Configuring UDP connection udp://mlat-1.fr24.com:19788
    2018-01-22 00:05:51 | [mlat][i]Registering MLAT station
    2018-01-22 00:05:51 | [mlat][i]Registering MLAT station: SUCCESS
    2018-01-22 00:05:52 | [feed][i]sent 1,0 AC
    2018-01-22 00:05:53 | [mlat][i]Received ADS-B time references AC:
    2018-01-22 00:05:53 | [mlat][i] 4CA96C
    2018-01-22 00:05:53 | [mlat][i]Pinging the server
    2018-01-22 00:05:53 | [mlat][i]Stats 11373197/11373197
    2018-01-22 00:05:57 | [feed][i]sent 4,0 AC
    2018-01-22 00:06:02 | [feed][i]sent 3,0 AC
    I'm at a loss as to what could cause this issue as I thought they'd be using the same method?

    The system doesn't have a firewall, and I can ping all of the NTP servers, so am really confused...

    Thanks,
    Chris

    Leave a comment:


  • Oblivian
    replied
    Originally posted by matthys View Post
    Why should I use sudo when I am root?
    Blame the scripted coding..

    We're finding all sorts of issues as you can see with recent posts with permissions and methods used to install associated

    Leave a comment:


  • matthys
    replied
    Originally posted by Oblivian View Post
    Because you didn't use SUDO

    But it is already latest.
    Why should I use sudo when I am root?

    Leave a comment:


  • Oblivian
    replied
    Originally posted by matthys View Post
    As a newby I'm not sure if this is the right topic to post.

    However I tried to update my old Raspberry Pi and notice there was a new fr24feed.
    But for some reason it's not going .. tried to remove and reinstall but get:

    root@debian512pi:~# apt-get install fr24feed
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    fr24feed is already the newest version.
    0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
    1 not fully installed or removed.
    After this operation, 0 B of additional disk space will be used.
    Do you want to continue [Y/n]? y
    Setting up fr24feed (1.0.19-5) ...
    /var/lib/dpkg/info/fr24feed.postinst: 35: /var/lib/dpkg/info/fr24feed.postinst: systemctl: not found
    /var/lib/dpkg/info/fr24feed.postinst: 47: /var/lib/dpkg/info/fr24feed.postinst: systemctl: not found
    dpkg: error processing fr24feed (--configure):
    subprocess installed post-installation script returned error exit status 127
    Errors were encountered while processing:
    fr24feed
    E: Sub-process /usr/bin/dpkg returned an error code (1)

    Still use the old version -> PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
    The apt sources.list contains -> deb <link> flightradar24 raspberrypi-stable
    Seems I cannot mention any links ....

    Any help how to solve this would be welcome.
    It only goes about the fr24feed, I use the original dump1090.

    Thanks,
    Matthijs
    Because you didn't use SUDO

    But it is already latest.

    Leave a comment:


  • matthys
    replied
    fr24feed broken (Raspberry Pi)

    As a newby I'm not sure if this is the right topic to post.

    However I tried to update my old Raspberry Pi and notice there was a new fr24feed.
    But for some reason it's not going .. tried to remove and reinstall but get:

    root@debian512pi:~# apt-get install fr24feed
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    fr24feed is already the newest version.
    0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
    1 not fully installed or removed.
    After this operation, 0 B of additional disk space will be used.
    Do you want to continue [Y/n]? y
    Setting up fr24feed (1.0.19-5) ...
    /var/lib/dpkg/info/fr24feed.postinst: 35: /var/lib/dpkg/info/fr24feed.postinst: systemctl: not found
    /var/lib/dpkg/info/fr24feed.postinst: 47: /var/lib/dpkg/info/fr24feed.postinst: systemctl: not found
    dpkg: error processing fr24feed (--configure):
    subprocess installed post-installation script returned error exit status 127
    Errors were encountered while processing:
    fr24feed
    E: Sub-process /usr/bin/dpkg returned an error code (1)

    Still use the old version -> PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
    The apt sources.list contains -> deb <link> flightradar24 raspberrypi-stable
    Seems I cannot mention any links ....

    Any help how to solve this would be welcome.
    It only goes about the fr24feed, I use the original dump1090.

    Thanks,
    Matthijs

    Leave a comment:


  • Oblivian
    replied
    Config file is for fixing bad settings, doesn't effect the start/stop.

    But from what most are experiencing there is some changes to permissions of files related to said run files.

    It's getting too tricky to fix them all so suggesting reimage and start fresh now.

    But the adjust to permissions a few posts back may help you too. Big unknowns

    Leave a comment:


  • ylis
    replied
    Originally posted by Oblivian View Post
    That generally means there is a serious error and it is crashing/not currently running

    You will need to use commandline to find out why or edit the config file.

    Assuming you are on a RPi, some of the commands are outlined.. https://forum.flightradar24.com/thre...ll=1#post74851

    you can also edit
    sudo nano /etc/fr24feed.ini
    OK - issue was fr24feed was not starting. Sudo fr24feed start got it going. And changes in fr24feed.ini are reflected in <ip_of_pi>:8754/settings.html.

    I now need to manually start the fr24feed each time. So how do I fix this ??

    From the various posts - I've tried sudo service fr24feed start ( and rebooted) and also sudo systemctl restart fr24feed.

    You mentioned editing the config file. Whats it called ? so I can have a look at it.

    Thanks

    Leave a comment:


  • Oblivian
    replied
    Originally posted by dotsi View Post
    After the update, I'm getting this error:

    Code:
    pi@raspberrypi:~ $ sudo service fr24feed status
    ● fr24feed.service - Flightradar24 Decoder & Feeder
       Loaded: loaded (/etc/systemd/system/fr24feed.service; enabled)
       Active: active (running) since Fri 2018-01-19 16:33:12 EET; 49s ago
      Process: 674 ExecStartPre=/bin/chmod a+rwx /var/log/lighttpd (code=exited, status=0/SUCCESS)
      Process: 666 ExecStartPre=/bin/chown -R nobody:nogroup /run/dump1090-mutability /var/log/fr24feed /run/fr24feed /dev/shm/decoder.txt (code=exited, status=0/SUCCESS)
      Process: 657 ExecStartPre=/bin/touch /dev/shm/decoder.txt (code=exited, status=0/SUCCESS)
      Process: 651 ExecStartPre=/bin/mkdir -p /run/dump1090-mutability /var/log/fr24feed /run/fr24feed /var/log/lighttpd (code=exited, status=0/SUCCESS)
      Process: 594 ExecStartPre=/usr/lib/fr24/install_dump1090.sh (code=exited, status=0/SUCCESS)
     Main PID: 683 (fr24feed)
       CGroup: /system.slice/fr24feed.service
               └─683 /usr/bin/fr24feed
    
    Jan 19 16:33:57 raspberrypi fr24feed[683]: Found 1 device(s):
    Jan 19 16:33:57 raspberrypi fr24feed[683]: 0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
    Jan 19 16:33:57 raspberrypi fr24feed[683]: usb_claim_interface error -6
    Jan 19 16:33:57 raspberrypi fr24feed[683]: Error opening the RTLSDR device: Device or resource busy
    Jan 19 16:33:57 raspberrypi fr24feed[683]: 2018-01-19 16:33:57 | [reader][i]Connection terminated
    Jan 19 16:33:57 raspberrypi fr24feed[683]: 2018-01-19 16:33:57 | [main][i]Terminating child process 1352 with SIGTERM
    Jan 19 16:33:58 raspberrypi fr24feed[683]: 2018-01-19 16:33:58 | [time][i]Synchronizing time via NTP
    Jan 19 16:33:59 raspberrypi fr24feed[683]: 2018-01-19 16:33:59 | [time][e]Failed to synchronize time
    Jan 19 16:34:01 raspberrypi fr24feed[683]: 2018-01-19 16:34:01 | [time][i]Synchronizing time via NTP
    Jan 19 16:34:01 raspberrypi fr24feed[683]: 2018-01-19 16:34:01 | [time][e]Failed to synchronize time
    If you look for the USB claim error you will find it's due to being in-use already by dump1090.

    Needs restart and checking how you start it (auto/manual)

    Leave a comment:


  • Oblivian
    replied
    Originally posted by helios View Post
    But then the fr24-directories also are owned by the user dump1090. I don't think it is neccessary for fr24feed to change the permissions of /run/dump1090-mutability; maybe only in case if there is no dedicated dump1090-mutability package installed.
    And going by my tests I think thats exactly what its based on.

    Leave a comment:


  • helios
    replied
    But then the fr24-directories also are owned by the user dump1090. I don't think it is neccessary for fr24feed to change the permissions of /run/dump1090-mutability; maybe only in case if there is no dedicated dump1090-mutability package installed.

    Leave a comment:


  • gleve
    replied
    Originally posted by helios View Post
    I ment to remove "/run/dump1090-mutability" from
    I left it there.

    Leave a comment:

Working...
X