Announcement

Collapse
No announcement yet.

Start with systemctl terminates connection to receiver

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • abcd567
    replied
    Originally posted by folkeorg View Post
    I noted that FlightAware is using dump1090-fa - is that another version? What is the difference to -mutability?
    Can "-fa" be used instead of "-mutability"?
    As already said by Oblivian, a better looking Map


    Originally posted by folkeorg View Post
    Also, I see in /etc/systemd/system/fr24feed.service that starting fr24feed is running a dumo1090-installation script. Does that affect the standalone-mode?
    The dump1090-mutability installation script first checks file /etc/fr24feed.ini. If it finds "receiver=dvbt", it proceeds with installation of colonized dump1090-mutability and mess your installation, particularly if you have installed dump1090-fa yourself. If it does not find "receiver=dvbt" but finds something else like "receiver=beast-tcp" etc, it halts and exits.

    If you have de-colonized the dump1090-mutability by method above, or if you have installed dump1090-fa yourself, never select option receiver="dvbt". Instead select receiver="beast-tcp" or receiver="avr-tcp".

    As an added protection, you may do this:
    In file /etc/systemd/system/fr24feed.service, comment-out the following line (i.e. place # at start of line) as shown below. Now the service will NOT run dump1090-mutability install script.

    # ExecStartPre=-/usr/lib/fr24/install_dump1090.sh

    Last edited by abcd567; 2021-03-03, 19:15.

    Leave a comment:


  • Oblivian
    replied
    Yes.. it has a better map. Which is why all the automated install scripts we've suggested so far include it

    No
    The feeder checks what you chose as 'receiver'. Per most guides and info here that deter the use of the bundled feeder, If you change it to dvbt. It will force that to run again. Regardless and stuff it again.

    And again, wiedehopf scripts sort that and remove it's ability from the service if you run them..


    Basically, fr24 don't care about your pi. They want your data. If you run their installer..or image. Its designed to feed them..only. and has faults.

    If you want more control, separating the process is the method to use. And you've done that.
    ​​​​​​​So now either start again using other than fr24 scripts that automate it and add features, Or leave it as is now. It will be fine.

    Leave a comment:


  • folkeorg
    replied
    I noted that FlightAware is using dump1090-fa - is that another version? What is the difference to -mutability?
    Can "-fa" be used instead of "-mutability"?

    Also, I see in /etc/systemd/system/fr24feed.service that starting fr24feed is running a dumo1090-installation script. Does that affect the standalone-mode?

    Leave a comment:


  • abcd567
    replied
    Originally posted by folkeorg View Post
    Oh, well the problem in kinda solved anyway but now another question arised..

    Is it better to have dump1090 read the receiver and fr24 and Piaware to get the data from a port-stream? I.e. are there multiple ways to feed data to fr24?

    I'm not really sure how this all is connected and works.
    when you install fr24feed, it automatically installs dump1090-mutability, and while installing colonizes it. The dump1090-mutability looses is stand-alone status. This has two disadvantage
    (1) In case of problems, debugging is difficult, not easy to find if problem is with fr24feed or dump1090+dvbt+antenna
    (2) For feeding multiple sites, stand-alone dump1090 provides flexibility.

    The method I posted in my above post de-colonizes dump1090-mutability, and it becomes a truly stand-alone application. The two disadvantages described above no more exist.

    Leave a comment:


  • folkeorg
    replied
    Maybe this installation that I have now is not optimal or "future-proof".

    I have four sites and one that I can use as a lab i.e. reinstall and play around with.

    Leave a comment:


  • folkeorg
    replied
    Oh, well the problem in kinda solved anyway but now another question arised..

    Is it better to have dump1090 read the receiver and fr24 and Piaware to get the data from a port-stream? I.e. are there multiple ways to feed data to fr24?

    I'm not really sure how this all is connected and works.

    Leave a comment:


  • abcd567
    replied
    Originally posted by folkeorg View Post
    I tried that..

    It seems that the dump1090 is not starting at all.
    Sorry, I forgot to mention that after making changes in setting (STEP-1 & 2), you had to reboot the Pi to implement the changes. Upon reboot the dump1090-mutability would have started automatically.

    I have now corrected my post (added STEP-3).

    Later, at any time you want to restart it, you can issued this command

    sudo systemctl restart dump1090-mutability



    .
    Last edited by abcd567; 2021-03-03, 00:21.

    Leave a comment:


  • folkeorg
    replied
    I uninstalled/purged fr24feed and reinstalled it. Now it seems that it is running "fine" .. still waiting for a flight to pass over..

    Leave a comment:


  • folkeorg
    replied
    I tried that..

    [I]2021-03-02 22:13:50 | [reader][i]Initializing reader
    2021-03-02 22:13:50 | [reader][i]Connecting to unknown receiver via (tcp://127.0.0.1:30005)
    2021-03-02 22:13:50 | [mlat]Waiting for MLAT configuration
    2021-03-02 22:13:50 | BeastBase::connectTcp(): Unable go connect, error: Connection refused[reader][e]Could not connect to tcp://127.0.0.1:30005


    It seems that the dump1090 is not starting at all.

    Leave a comment:


  • abcd567
    replied

    STEP-1: Make dump1090-mutability free to start on its own, and not be slave of fr24feed

    Code:
    sudo dpkg-reconfigure dump1090-mutability
    Above command will open a window which will ask "start dump1090 automatically" with NO and YES buttons. The NO button will be red. Use TAB key to make YES button red. Press Enter key to accept YES.

    Whenever you press Enter key, the window will change to another config item. Keep on pressing Enter key to accept default values.

    The onlything you have to enter is your latitude and longitude when asked for.

    At one screen pressing Enter will not move screen to next step as OK button will not be red. Make OK button red by pressing TAB key.

    Continue till the configuration window closes itself.


    STEP-2: Modify config to suite an independent dump1090-mutability

    1 - Open file /etc/fr24feed.ini for editing

    sudo nano /etc/fr24feed.ini
    You will see this:
    Code:
    receiver="dvbt"
    fr24key="xxxxxxxxxxxxxxxx"
    path="/usr/lib/fr24/dump1090"
    bs="yes"
    raw="yes"
    logmode="1"
    logpath="/var/log/fr24feed"
    mlat="yes"
    mlat-without-gps="yes"
    2- Make following changes:
    Change receiver="dvbt" to receiver="beast-tcp"

    Change path="/usr/lib/fr24/dump1090" to host="127.0.0.1:30005"

    Change bs=“yes” to bs=“no”

    Change raw=“yes” to raw=“no”

    The file will become like this:

    Code:
    receiver="beast-tcp"
    fr24key="xxxxxxxxxxxxxxxx"
    host="127.0.0.1:30005"
    bs="no"
    raw="no"
    logmode="1"
    logpath="/var/log/fr24feed"
    mlat="yes"
    mlat-without-gps="yes"
    3 - Save file (Ctrl+O) and Close file (Ctrl+x)

    STEP-3: Reboot the Pi to implement the changes made.

    At reboot, the dump1090-mutability will be automatically started as stand-alone app by the system.

    Code:
    sudo reboot

    .
    Last edited by abcd567; 2021-03-03, 00:14.

    Leave a comment:


  • Oblivian
    replied
    It doesn't look working on the 2nd lot. It's probably doing the same, just reporting less.

    See all the pings. That's no data received.

    Also likely related to existing thread and setup..so doesn't really warrant it's own when you are fault finding there already

    Leave a comment:


  • folkeorg
    replied
    What do you mean with "standalone decoder"? Not a DVB-T stick? What other HW is there?

    Leave a comment:


  • wiedehopf
    replied
    As i've written somewhere else, fr24feed isn't programmed too well and i wouldn't use the DVB-T option ever.
    Using a standalone decoder with fr24feed using the data from that decoder is much more reproducible.

    > 2021-03-02 12:18:16 | [reader][i]Configured, processing messages
    > 2021-03-02 12:18:16 | [reader][i]Connection terminated

    fr24feed doesn't give you any information of why the internal dump1090-mutability exited nor the output from that program it started.
    That makes it completely useless to solve the issue.

    fr24 employees seldom show on the forum and people who usually help out fellow enthusiasts won't be able to help you with a program they don't control.

    As such ... i'd recommend opening a ticket or using a standalone decoder.

    Leave a comment:


  • Start with systemctl terminates connection to receiver

    If I start the fr24feed with "systemctl" then I get (cyclic-loop):

    [I]2021-03-02 12:18:16 | [reader][i]Connecting to DVBT receiver via (exe:///usr/bin/dump1090-mutability --raw --mlat)
    2021-03-02 12:18:16 | [reader][i]Connected to the receiver, configuring
    2021-03-02 12:18:16 | [reader][i]Configured, processing messages
    2021-03-02 12:18:16 | [reader][i]Connection terminated
    2021-03-02 12:18:16 | [main][i]Terminating child process 1214 with SIGTERM
    2021-03-02 12:18:21 | [reader]Connecting to DVBT receiver via (exe:///usr/bin



    But if I start with "sudo fr24feed" then it works well:

    [I]2021-03-02 12:23:58 | [feed][n]connecting
    2021-03-02 12:23:58 | [feed][n]connected via UDP (fd 27)
    2021-03-02 12:23:58 | [feed]Feed connected
    2021-03-02 12:23:58 | [feed][n]working
    2021-03-02 12:24:28 | [feed][n]ping 1
    2021-03-02 12:24:29 | [feed][n]syncing stream result: 1
    2021-03-02 12:24:58 | [feed][n]ping 2


    Why is there a difference?

    On my other RPi I don't have this issue and they run the same OS etc.
Working...
X