No announcement yet.

Why did my feeder stop working and won't start again?

  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    When I am going to buy a new one, which cheap one from could you suggest?


    • #17
      On Jan 5th I bought this one: Nooelec NESDR SMArt v4 SDR - Prämie RTL-SDR mit Alu Gehäuse, 0,5 PPM TCXO, SMA Input.

      It is not available right now, the V2 is available.
      But I guess it is NOT a hardware related problem. Both of my sticks run into the same problem. After a power-on reset both do the initialisation, and work fine. After some time (up to 2 days) they are in an endless loop with the information

      [mlat][i]No ADS-B time reference available (0/0)
      shown in the log. This led me to changing the setup, I have turned MLAT off now and keep monitoring it.

      Later today or tomorrow I can give you an update to this. But you could try to do a power-on reset and look into the log file. If the same happens on your system, try to turn MLAT off.


      • #18
        I have NOT enabled MLAT.


        • #19
          Irrelevant. MLAT wont actually start from fresh boot unless it sees planes/data to be able to.

          If your USB stick is not seeing any, and then FR24 is sending an auto reset to try flush it, but not coming back. It's probably 'wedging' and sticking in a 'I can't actually talk to the stick' loop.

          The only way to tell if it is, is to quit fr24 and run dump1090 on its own and monitor the direct connection logs.

          You're basically trying to diagnose something from a 2nd level and FR24 can't see very deep.

          FR24->Dump1090->USB - FR24 cant see the USB directly. It's launching dump1090 that does, and has no way of passing back whats going on

          Dump1090->USB, will however.

          Multiple things cause it, overheating sticks, bad shutdown/restart command, bad power supply. USB extension cables
          Posts not to be taken as official support representation - Just a helpful uploader who tinkers


          • #20
            Thanks Oblivian!
            I do not want to dive deeply into this software - which obviously is quite vulnerable.

            At a termperature of 0° C it won't be an overheated DVBT stick, I replaced the powersupply two times, the PI4 in use did a good job at higher temperatures over a whole year, the wifi connection is verifyed and stable, as well as the internet connection. Despite some helpful information in the log and some timed loops for reconnecting after communication time-out: in my understanding it is just a really lousy and not properly tested SW provided by FR24 without any debugging aids and I will stop spending my time with it. I use the equipment and firmware they specify. Maybe they come back with a solution some day. The performance of the FR24 server structure also seems to contribute to the problems, I see many time outs accessing the web site and even the forum.

            They want me to upload data for them, so they should provide a reliable solution.

            The problem returned again twice today, it only can be solved temporarily by a hardware reset. And it is not my job to turn decives off and on every few hours.
            Yes, it makes me angry - any support provided so far is to ask for more data form a log file, which cannot and does not show the required data for debugging. A very common way to keep one busy and avoid effort for problem solving.


            • #21
              I hear ya. But as you see by the lack of interaction here short of saying 'email support' where noone else gains from the fix or info, theres little else to to.
              (I've even stopped visiting or trying to stop the spam accounts joining to make others experience better, but noones willing to help, so I'm out)

              The alternate is use abcd guide to change to dump1090-fa and the reconfigure the feeder to get it's source from beast-tcp
              or wiedehopf auto reconfigure/fix it script that does it all for you.
              Posts not to be taken as official support representation - Just a helpful uploader who tinkers


              • #22
                update: now the connection is terminated every time I try to start the Raspi+DVBT
                Power-on reset is not working any more. And it is the same effect with both of my DVBT nooelec sticks. I'll try to provide more information to the support right now. But I don't believe in miracles.


                • #23
                  Go and give this a try:

                  You can just install readsb and the other mentioned things on the fr24 image if you have that running, it will just reconfigure fr24.

                  In the readme for installing readsb it also should tell you how to check the log for it.
                  It talks to the SDR.

                  In case you are gonna give that a try and the issue comes back, post the logs please


                  • #24
                    None of you updated your pi OS (or let it auto update) to bullseye per chance
                    might be an influx if dump1090-mutability suddenly stops on it since fr24 chose/packaged it as default.
                    Posts not to be taken as official support representation - Just a helpful uploader who tinkers


                    • #25
                      No change was made in the PI Image. It is as provided by FR24.


                      • #26
                        It wouldn't be the first time a self imposed breaking change was made.

                        I'd expect a lot more broken by now if it was. But should rule it out
                        cat /etc/os-release

                        Buster/stretch is expected. 9/10

                        11 would be a change

                        Posts not to be taken as official support representation - Just a helpful uploader who tinkers


                        • #27
                          You have to manually intervene to update from buster to bullseye.

                          No way this would happen automatically, it breaks far too easily on update.


                          • #28
                            Fair enough.

                            Given the track record and 3 people reporting similar. in the same week. With most not willing to try further. It was a last ditch reach.
                            Posts not to be taken as official support representation - Just a helpful uploader who tinkers


                            • #29
                              Regarding OS release:

                              PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
                              NAME="Raspbian GNU/Linux"
                              VERSION="10 (buster)"

                              Given the situation, I'd expect some useable documentation and test procedures to envoke. Installing other decoding software is not solving the problem. Is there a "second level" of logging, which would allow a deeper insight to the developers?

                              I want to see a stable systems before installing further systems in Austria and Bavaria. I guess FR24 is interested to get more data from other regions.


                              • #30
                                Installing an independent decoder is the solution.

                                It also lets you share data with other aggregators like adsbexchange / flightaware / radarbox / planefinder / opensky / ............

                                If you want to communicate with FR24 directly, it might be better to open tickets, the forum doesn't seem to be frequented much by people who actually work on fr24feed.