Announcement

Collapse
No announcement yet.

dump1090-fa periodically failing to receive messages

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

  • dump1090-fa periodically failing to receive messages

    With reference to this, can anyone help me understand what is going on here please?

    Chart.JPG

    A few times a week my setup will fail to receive and aircraft messages. I have replaced the RTL-SDR.COM dongle, tried a different Pi, with a new SD card (same image though) and swapped in a different power supply. I am now wondering if this may be a fault with the only other module in the chain, the RTL-SDR Triple Filtered LNA.

    I could obviously just remove this filter but if the issue goes, that might not prove anything if it is a load problem, or some issue with the software activation of the bias-T circuit, etc. I really would rather not buy another filter unless the advice is that it is the most likely cause. The problem will always resolve itself after an hour or two. Is it possible that the LNA/Filter could behave in this way, or might this be a software or other issue?

    I did consider writing a cron job to look for " no new messages received in" in the journalctl output and turn the bias-T feed off an on, but wonder if that is worthwhile or the best way to monitor this issue?

    I have included a chunk of output from journalctl during the period that nothing is being received in case it is of help.

    Cheers


    Aug 06 20:14:37 raspberrypi piaware[458]: no new messages received in 3887 seconds, it might just be that there haven't been any aircraft nearby but I'm going to try
    Aug 06 20:14:37 raspberrypi piaware[458]: faup1090 exited with SIG SIGHUP
    Aug 06 20:14:37 raspberrypi piaware[458]: attempting to restart dump1090..
    Aug 06 20:14:38 raspberrypi sudo[27051]: piaware : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/sbin/invoke-rc.d --query dump1090-fa restart
    Aug 06 20:14:38 raspberrypi sudo[27051]: pam_unix(sudo:session): session opened for user root by (uid=0)
    Aug 06 20:14:38 raspberrypi sudo[27051]: pam_unix(sudo:session): session closed for user root
    Aug 06 20:14:39 raspberrypi piaware[458]: attempting to restart dump1090-fa using 'systemctl --no-block try-restart dump1090-fa.service < /dev/null'...
    Aug 06 20:14:39 raspberrypi sudo[27062]: piaware : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/systemctl --no-block try-restart dump1090-fa.service
    Aug 06 20:14:39 raspberrypi sudo[27062]: pam_unix(sudo:session): session opened for user root by (uid=0)
    Aug 06 20:14:39 raspberrypi sudo[27062]: pam_unix(sudo:session): session closed for user root
    Aug 06 20:14:39 raspberrypi dump1090-fa[26315]: Thu Aug 6 20:14:39 2020 BST Caught SIGTERM, shutting down..
    Aug 06 20:14:39 raspberrypi systemd[1]: Stopping dump1090 ADS-B receiver (FlightAware customization)...
    Aug 06 20:14:39 raspberrypi dump1090-fa[26315]: Thu Aug 6 20:14:39 2020 BST Waiting for receive thread termination
    Aug 06 20:14:39 raspberrypi piaware[458]: dump1090 restart appears to have been successful
    Aug 06 20:14:41 raspberrypi dump1090-fa[26315]: Thu Aug 6 20:14:41 2020 BST Normal exit.
    Aug 06 20:14:41 raspberrypi piaware[458]: mlat-client(9867): Lost connection to localhost:30005
    Aug 06 20:14:41 raspberrypi piaware[458]: mlat-client(9867): Reconnecting in 30.0 seconds
    Aug 06 20:14:41 raspberrypi systemd[1]: dump1090-fa.service: Succeeded.
    Aug 06 20:14:41 raspberrypi systemd[1]: Stopped dump1090 ADS-B receiver (FlightAware customization).
    Aug 06 20:14:41 raspberrypi piaware[458]: mlat-client(9867): Beast-format results connection with 127.0.0.1:30104: connection lost
    Aug 06 20:14:41 raspberrypi systemd[1]: Starting dump1090 ADS-B receiver (FlightAware customization)...
    Aug 06 20:14:41 raspberrypi dump1090-fa[27075]: Found 1 device(s):
    Aug 06 20:14:41 raspberrypi dump1090-fa[27075]: 0: Realtek, RTL2838UHIDIR, SN: 00000001
    Aug 06 20:14:41 raspberrypi dump1090-fa[27075]: Using device 0: Generic RTL2832U OEM
    Aug 06 20:14:41 raspberrypi dump1090-fa[27075]: Found Rafael Micro R820T tuner
    Aug 06 20:14:42 raspberrypi systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
    Aug 06 20:14:43 raspberrypi dump1090-fa[27080]: Thu Aug 6 20:14:43 2020 BST dump1090-fa 3.7.1 starting up.
    Aug 06 20:14:43 raspberrypi dump1090-fa[27080]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
    Aug 06 20:14:43 raspberrypi dump1090-fa[27080]: Found Rafael Micro R820T tuner
    Aug 06 20:14:43 raspberrypi dump1090-fa[27080]: rtlsdr: tuner gain set to 36.4 dB
    Aug 06 20:14:44 raspberrypi dump1090-fa[27080]: Allocating 4 zero-copy buffers
    Aug 06 20:14:50 raspberrypi sudo[27087]: piaware : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/netstat --program --tcp --wide --all --numeric
    Aug 06 20:14:50 raspberrypi sudo[27087]: pam_unix(sudo:session): session opened for user root by (uid=0)
    Aug 06 20:14:50 raspberrypi sudo[27087]: pam_unix(sudo:session): session closed for user root
    Aug 06 20:14:50 raspberrypi piaware[458]: ADS-B data program 'dump1090-fa' is listening on port 30005, so far so good
    Aug 06 20:14:50 raspberrypi piaware[458]: Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout
    Aug 06 20:14:50 raspberrypi piaware[458]: Started faup1090 (pid 27096) to connect to dump1090-fa
    Aug 06 20:15:01 raspberrypi CRON[27097]: pam_unix(cron:session): session opened for user pi by (uid=0)
    Aug 06 20:15:01 raspberrypi CRON[27102]: (pi) CMD (/usr/bin/sudo -H /usr/local/bin/checkwifi.sh >>/home/pi/logs/reset_wifi.log 2>&1)
    Aug 06 20:15:01 raspberrypi sudo[27103]: pi : TTY=unknown ; PWD=/home/pi ; USER=root ; COMMAND=/usr/local/bin/checkwifi.sh
    Aug 06 20:15:01 raspberrypi sudo[27103]: pam_unix(sudo:session): session opened for user root by (uid=0)
    Aug 06 20:15:03 raspberrypi sudo[27103]: pam_unix(sudo:session): session closed for user root
    Aug 06 20:15:03 raspberrypi CRON[27097]: pam_unix(cron:session): session closed for user pi
    Aug 06 20:15:10 raspberrypi piaware[458]: 3227397 msgs recv'd from dump1090-fa (0 in last 5m); 3226629 msgs sent to FlightAware
    Aug 06 20:15:11 raspberrypi piaware[458]: mlat-client(9867): Input connected to localhost:30005
    Aug 06 20:15:11 raspberrypi piaware[458]: mlat-client(9867): Input format changed to BEAST, 12MHz clock
    Aug 06 20:10:07 raspberrypi piaware[458]: 3227397 msgs recv'd from dump1090-fa (0 in last 5m); 3226629 msgs sent to FlightAware

    Attached Files

  • #2
    Check for undervoltage: https://github.com/wiedehopf/adsb-wi...s#undervoltage

    Lots of intermittent issues are power supply issues.

    Comment


    • #3
      Originally posted by wiedehopf View Post
      Check for undervoltage: https://github.com/wiedehopf/adsb-wi...s#undervoltage

      Lots of intermittent issues are power supply issues.
      Thank you for these links. Here's what I get

      sudo dmesg --ctime | grep voltage returns nothing


      And the throttled script this:

      Status: 0x0
      Undervolted:
      Now: NO
      Run: NO
      Throttled:
      Now: NO
      Run: NO
      Frequency Capped:
      Now: NO
      Run: NO
      Softlimit:
      Now: NO
      Run: NO

      I wasn't sure if this last script needed to be run while the issue was occurring?

      Comment


      • #4
        It's now in the failed state and no amount of restarting dump1090-fa is helping.

        I stopped and restarted the bias-T to the LNA and is started receiving messages for a short while, but is now back to receiving nothing. Not sure if that means anything?

        Comment


        • #5
          It's now been online but not receiving messages for 7 hours, without correcting itself. What I now know is this:
          • sudo systemctl restart dump1090-fa - has no effect, although once in a while I get "Warning: The unit file, source configuration file or drop-ins of dump1090-fa.service changed on disk. Run 'systemctl daemon-reload' to reload units." Don't know what that is telling me either.
          • Reseting the WiFi with ip link set wlan0 down; ip link set wlan0 up has no effect.
          • sudo systemctl stop dump1090-fa followed by ./rtl_biast -b 0 always restores the service for a minute or so.
          Might this be a problem with the Pis ability to power the LNA? Should I be running that with it's own supply, maybe?

          I'm now going to physically turn it off for a few minutes to see if that fixes it?
          Last edited by ThePhoenix; 2020-08-07, 19:42.

          Comment


          • #6
            I use my tripple filtered LNA with an external power supply through a Bias-T. No headaches of Pi or dongle insufficiently or intermittently powering the LNA.

            Resizer_15681533959180.jpg

            Comment


            • #7
              Originally posted by abcd567 View Post
              I use my tripple filtered LNA with an external power supply through a Bias-T. No headaches of Pi or dongle insufficiently or intermittently powering the LNA.

              Resizer_15681533959180.jpg
              Normal service has been resumed. I didn't turn it off in the end, I did this:
              sudo systemctl stop dump1090-fa; pause 60s; ./rtl_biast -b 0 and it has been up and running since.

              I imagine that you are thinking that this is the solution to my issues? I'll have to knock myself up a diy Bias Tee module. Would you be happy to share the values of the cap(s) and inductor(s) you are using? Or is that an off-the-shelf unit?

              BTW would you know the reason I sometimes get this warning when restarting dump1090-fa and what it is actually telling me: "Warning: The unit file, source configuration file or drop-ins of dump1090-fa.service changed on disk. Run 'systemctl daemon-reload' to reload units."?

              Thank you.
              Last edited by ThePhoenix; 2020-08-07, 21:26.

              Comment


              • #8
                Off the shelf Bias-T

                https://www.ebay.com/itm/183755341046


                s-l400-1.jpg


                s-l400-2.jpg
                .


                DIY Bias-T

                image_4704.jpg

                .
                Last edited by abcd567; 2020-08-07, 23:40.

                Comment


                • #9
                  That's excellent.

                  Ordered. It should be here on Monday.

                  Thank you very much.

                  Comment


                  • #10
                    Take care when connectiing. On bias-t, one sma connector has dc voltage and should be connected to LNA. The other sma has no dc and should be connected to dongle.

                    Unfortunately many bias-t dont have markings to identify. The only way is either measure dc on both connectors, or locate the isolating capacitor on pcb. The isolating capacitor is on the central strip of only one of the two sma connectord. The sma connector with capacitor does not get dc and should be connected to dongle.

                    You will also need a 5v dc adaptor to feed power to bias-t. Please see the ohoto of my setup in my first post.

                    Comment


                    • #11
                      I'm very grateful.

                      Thank you for taking the time.

                      Comment


                      • #12
                        Just installed the Bias-T module (having remember to shut down the request to start the on-board Bias-T on the SDR dongle). All is working fine.

                        Since posting here and before the module arrived I have discovered the failure I am trying to resolve occurs when the ambient temperature exceeds approx 38°C. I am hoping that this is because the SDR dongle's Bias-T circuit cuts out, in which case my stand-alone module may fix the issue. If however it is something in the LNA/Filter that is overheating, then I think I will need to be building myself some sort of cooling system.

                        Report back with findings as soon as tomorrow, if the weather is as hot as it has been during the last week.

                        Comment

                        Working...
                        X