Announcement

Collapse
No announcement yet.

Archived - Beta test MLAT software for Raspberry Pi

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

    There's now a new version 1.0.16-11 that addresses the issue. For those of you who are affected, please update your feeder to the latest version with:

    Code:
    sudo /usr/lib/fr24/fr24feed_updater.sh
    Apologies for any inconvenience!

    Comment


      Thats looking a bit healthier

      Now to find out what is resetting my clock 46years. Anyone else seeing that (youll need to run sudo fr24feed start without 'service')
      Posts not to be taken as official support representation - Just a helpful uploader who tinkers

      Comment


        Originally posted by piopawlu View Post
        There's now a new version 1.0.16-11 that addresses the issue.
        Apologies for any inconvenience!
        Great - all fixed now - thanks for quick turnaround on that one

        Comment


          Originally posted by Oblivian View Post
          Thats looking a bit healthier

          Now to find out what is resetting my clock 46years. Anyone else seeing that (youll need to run sudo fr24feed start without 'service')
          No not seeing that but I did a full distro update to clean up any other woolie problems. (Jessie)

          Comment


            Originally posted by Kemistry View Post
            No not seeing that but I did a full distro update to clean up any other woolie problems. (Jessie)
            I thought I had..

            Just turned off local router NTP relay to ensure it was getting time from external. But alas

            2016-01-29 00:07:34 | [feed][n]ping 2
            2016-01-29 00:07:48 | ERROR: time drift is 1453979257 seconds, resetting dump1090 start time[mlat][i]Pinging the server

            At least its not as regular now, I was getting screens full
            Posts not to be taken as official support representation - Just a helpful uploader who tinkers

            Comment


              Originally posted by Oblivian View Post
              I thought I had..

              Just turned off local router NTP relay to ensure it was getting time from external. But alas

              2016-01-29 00:07:34 | [feed][n]ping 2
              2016-01-29 00:07:48 | ERROR: time drift is 1453979257 seconds, resetting dump1090 start time[mlat][i]Pinging the server

              At least its not as regular now, I was getting screens full
              It took a little while for me to figure out what happened, I noticed Kemistry was offline for a while and then realised it might have something to do with the latest version and updating etc etc... I have updated to 1.0.16-11.........Now I am getting the following errors by the gazillion:

              2016-01-28 23:10:32 | ERROR: time drift is 1435634555 seconds, resetting dump1090 start timeERROR: time drift is 1435634503 seconds, resetting dump1090 start timeERROR: time drift is 1435634480 seconds, resetting dump1090 start timeERROR: time drift is 1435634436 seconds, resetting dump1090 start timeERROR: time drift is 1435634412 seconds, resetting dump1090 start timeERROR: time drift is 1435634396 seconds, resetting dump1090 start timeERROR: time drift is 1435634358 seconds, resetting dump1090 start timeERROR: time drift is 1435634339 seconds, resetting dump1090 start timeERROR: time drift is 1435634303 seconds, resetting dump1090 start timeERROR: time drift is 1435634280 seconds, resetting dump1090 start timeERROR: time drift is 1435634261 seconds, resetting dump1090 start timeERROR: time drift is 1435634233 seconds, resetting dump1090 start timeERROR: time drift is 1435634185 seconds, resetting dump1090 start timeERROR: time drift is 1435634149 seconds, resetting dump1090 start timeERROR: time drift is 1435634135 seconds, resetting dump1090 start timeERROR: time drift is 1435634119 seconds, resetting dump1090 start timeERROR: time drift is 1435634096 seconds, resetting dump1090 start timeERROR: time drift is 1435634078 seconds, resetting dump1090 start timeERROR: time drift is 1435634009 seconds, resetting dump1090 start timeERROR: time drift is 1435633979 seconds, resetting dump1090 start timeERROR: time drift is 1435633944 seconds, resetting dump1090 start timeERROR: time drift is 1435633930 seconds, resetting dump1090 start timeERROR: time drift is 1435633918 seconds, resetting dump1090 start timeERROR: time drift is 1435633877 seconds, resetting dump1090 start timeERROR: time drift is 1435633860 seconds, resetting dump1090 start time[mlat][i]Pinging the server

              My clock is NOT wildly out of sync, I still haven't figured out why this even needs to happen, none of the ADS-B / Mode-S MLAT calculations depend on the system clock.... For now I've stopped feeding till I can see this is fixed...
              Last edited by bhaal; 2016-01-28, 13:17. Reason: Add version number
              T-YBBN50 - Kallangur, QLD, Australia

              Comment


                Also, when are you going to get Mode-S -> MLAT working via "avr-tcp" etc ??? I don't wish to have fr24feed being responsible for firing off dump1090 ... I don't understand why it's required... And so far, no one has explained why they think its required.
                T-YBBN50 - Kallangur, QLD, Australia

                Comment


                  Originally posted by bhaal View Post
                  Also, when are you going to get Mode-S -> MLAT working via "avr-tcp" etc ??? I don't wish to have fr24feed being responsible for firing off dump1090 ... I don't understand why it's required... And so far, no one has explained why they think its required.
                  It is actually not required and it worked just fine with avr-tcp. However, volunteer MLAT was disabled for technical reasons some time ago. We are hoping to enable it back next week.

                  The error you are getting does not depend on your local clock, the message itself is ambiguous and is fixed in the upcoming release. The problem occurs when timestamps from dump1090 are drifting much faster than they should.

                  Comment


                    Originally posted by piopawlu View Post
                    It is actually not required and it worked just fine with avr-tcp. However, volunteer MLAT was disabled for technical reasons some time ago. We are hoping to enable it back next week.

                    The error you are getting does not depend on your local clock, the message itself is ambiguous and is fixed in the upcoming release. The problem occurs when timestamps from dump1090 are drifting much faster than they should.
                    Just want to confirm, if "avr-tcp" and "beast-tcp" feeders can both contributing to FR24 MLAT starting this version?

                    As I know, the previous version of fr24feed block all other sources except USB DVB-T Stick for contributing FR24 MLAT.

                    Comment


                      Originally posted by piopawlu View Post
                      It is actually not required and it worked just fine with avr-tcp. However, volunteer MLAT was disabled for technical reasons some time ago. We are hoping to enable it back next week.

                      The error you are getting does not depend on your local clock, the message itself is ambiguous and is fixed in the upcoming release. The problem occurs when timestamps from dump1090 are drifting much faster than they should.
                      I'm encountering the same time errors. So when I got you right, this issue will be addressed in a release higher than the current .11 ?

                      Comment


                        Originally posted by bhaal View Post
                        Also, when are you going to get Mode-S -> MLAT working via "avr-tcp" etc ??? I don't wish to have fr24feed being responsible for firing off dump1090 ... I don't understand why it's required... And so far, no one has explained why they think its required.
                        It only launches Dump1090 when using a DVB-T unit and DVB-T is defined.

                        It's required as that's what initiates the USB device and tunes the right frequency to be able to receive from a DVB Stick.

                        From my brief testing, Other feeder types connect to data feed directly like the old software on 30003. Status is usually 'connecting to x receiver' and no mention of Dump1090. Check it out yourself by dropping the 'service' command and change the feeder type a few times.

                        I use it port 30002, as I run Mutability independently, and as far as I can tell it doesn't run Dump1090 a 2nd time, and I get MLAT statistics fine (when its enabled) and T-MLAT6 has it down as low as 400ft around here, and theres not that many Pi users in my area that I know of.
                        Last edited by Oblivian; 2016-01-29, 02:04.
                        Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                        Comment


                          Originally posted by Oblivian View Post
                          From my brief testing, Other feeder types connect to data feed directly like the old software on 30003. Status is usually 'connecting to x receiver' and no mention of Dump1090. Check it out yourself by dropping the 'service' command and change the feeder type a few times.

                          I use it port 30002, as I run Mutability independently, and as far as I can tell it doesn't run Dump1090 a 2nd time, and I get MLAT statistics fine (when its enabled) and T-MLAT6 has it down as low as 400ft around here, and theres not that many Pi users in my area that I know of.
                          Still very new here and trying to understand things. By "Mutability" are you referring to dump1090 mutability? And are you actually able to contribute ads-b based data to T-MLAT6 type radar tag sources with an RPi and fr24feed by using dump1090 mutability?

                          I'm a little confused because piopawlu said above that user pi MLAT was disabled for now.

                          Also, is this fr24 pi update broken for everyone? Is there a way to down rev if the beta doesn't work?
                          TIA .

                          Comment


                            Originally posted by Sam26K View Post
                            Still very new here and trying to understand things. By "Mutability" are you referring to dump1090 mutability? And are you actually able to contribute ads-b based data to T-MLAT6 type radar tag sources with an RPi and fr24feed by using dump1090 mutability?

                            I'm a little confused because piopawlu said above that user pi MLAT was disabled for now.

                            Also, is this fr24 pi update broken for everyone? Is there a way to down rev if the beta doesn't work?
                            TIA .
                            Yes. Its open source - there are various versions of Dump1090. FR use their own based on Malcom Robb fork, I use the one included with PiAware (-mutability). Most of them add the --MLAT tag that has been mentioned. Which is a time tag to packets sent out.

                            Yes, it is currently disabled. Thats why we mentioned twice in your other thread, that it is currently DOWN. And I clearly pointed out there, Raspberry Pi contributions show as T-MLAT6/7

                            That doesn't mean they have turned it off for everyones CLIENT side.

                            Data appears to still being sent. Its just not being publicly displayed while they work on it. Else they can't test and work on it with no data...
                            Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                            Comment


                              OK, I think I'm starting to understand, please pardon my noobness. So this beta update time stamp problem is a client MLAT dump1090 mutability problem?

                              The peer to peer MLAT pi thing sounds interesting but just still cautious about breaking my working pi fr24 live feeder .

                              Comment


                                Vinny/piopawlu et-al

                                Can you double check the coding on the built in web-page examples. Still has the MPX/SBS feed listed as 10001 - pretty sure this opens port 20072 given testing does it not? And you still specify 10001 as the incoming port in host/IP
                                Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                                Comment

                                Working...
                                X