Announcement

Collapse
No announcement yet.

Flightradar24 Feeder Chat

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

  • Originally posted by Mike View Post
    New FR24 receivers

    F-RODN1 activated in Okinawa, Japan
    A quick glance and it seems that the range from F-RODN1 is very good. Much better tracking for flights from Japan heading to Singapore/ Shanghai to Australia east of Naha now.

    Comment


    • Originally posted by Mike View Post
      The screenshot is not enough to determine what data your receiver was providing and when. Our primary goal is quality and quantity is secondary. One data point is not enough, as we historically have seen that one point, especially the first one, very often can be incorrect, and people are spamming social media with aircraft shown off track. Full data for one point from several feeders or 2-3 points from one feeder are needed before it's drawn on FR24. If you add the processing time at FR24, it can take 20-120 seconds from that you get first LON/LAT in your local software until FR24 is confident with the data quality and process the data for the map. If the coverage is good this is normally not a problem.

      In this case if you look on playback first data was on 15875 feet and your screenshot is 17825 so your data was used before that, but it has just not showed up on map yet when you took the screenshot.
      Thanks so much for the clarification. I'll attach you a shot when I had the plane @ 14k feets and another shot documenting another case.
      fr242.png
      fr243.png

      Comment


      • Sorry but I can't do absolutely nothing with one or two screenshots. The screenshot does not say what data was decoded and when. I have clearly clarified how the system works and what is needed for data to be presented on FR24.

        In this case maybe location was decoded at 14.000 feet, and but altitude. Later on altitude on 14.875 feet altitude was decoded but not position. Your software merge this position and altitude data and show an aircraft at position X and alt Y on your map. FR24 does not have full data and is not using/processing this data. Or maybe 14.875 feet was first time full data was received, 15.575 feet was second and 15.875 feet was third and now FR24 processed the data and showed it on FR24. Without the full raw data I can only speculate.

        Comment


        • Originally posted by Mike View Post
          Sorry but I can't do absolutely nothing with one or two screenshots. The screenshot does not say what data was decoded and when. I have clearly clarified how the system works and what is needed for data to be presented on FR24.

          In this case maybe location was decoded at 14.000 feet, and but altitude. Later on altitude on 14.875 feet altitude was decoded but not position. Your software merge this position and altitude data and show an aircraft at position X and alt Y on your map. FR24 does not have full data and is not using/processing this data. Or maybe 14.875 feet was first time full data was received, 15.575 feet was second and 15.875 feet was third and now FR24 processed the data and showed it on FR24. Without the full raw data I can only speculate.
          If it happens again i'll get the dump1090 output

          Comment


          • Mike,

            Here's another one this morning not showing up until approx. 60km's nth/west of SYD. The offending aircraft is SIA212 which has departed SYD and is three quarters of the way to KAT (Katoomba) NDB, with the aircraft behind, VOZ553 displaying correctly for a comparison. I appreciate that a couple of images doesn't help a great deal but it does clearly indicate an issue with the map. There's also very little extra information that we can actually offer you except to show you the problem. Playback from 22:30UTC (2014_10_25) will show the issue as it happens (although it's the 26th here atm). Please don't shoot the messenger, the 'quality' of the map you mention is being compromised, something which concerns many of us.

            If we're wasting our time and effort in alerting you to issues with the map let us know. I don't have much of either left.

            SQ212.jpg VOZ553.jpg

            Regards,
            Gregg
            Last edited by fungus; 2014-10-25, 23:27.
            YSSY2/T-YSSY4 [SBS-1 Basestation w/- SSE-1090 SJ Mk2 Antenna (Thanks Delcomp) ] [Uniden UBCD996T w/- 16 element Wideband Discone VHF/UHF Antenna, and tuned 108MHz-137MHz Airband Antenna] [Trialing a home-brew 1090MHz collinear antenna]

            Comment


            • Thanks Fungus, as I wrote 3 posts up.

              Sorry but I can't do absolutely nothing with one or two screenshots. The screenshot does not say what data was decoded and when.
              We are quite confident that there are no errors, and the only way to check that is to have the raw receiver data, not a screenshot.

              Comment


              • Mike,

                From what I'm seeing I don't share your confidence. I fail to see what part of 'multiple errors' regarding aircraft failing to appear on the map when they should do so (noted by the screenshots and the fact they are displaying correctly on my receiver) is not an issue for you to be concerned about, let alone so blase (that's 'unconcerned' or 'indifferent'). The reasons why and the technical aspects as to what is occurring are not for us to be able to answer since we are told nothing relating to the 'raw data' side of FR24 (afterall, I'm just a 'flyswatter' on the chat). We simply aren't all privy to it and surely cant be expected to provide such data. We cant be expected to have access to all the raw data of all the feeders in the Sydney area, that's just plain ridiculous. It simply seemed to be something that has only been occurring lately which didn't occur in the past. Thus worth noting and advising you about (or so I thought). I've got other examples, I just don't have the energy to go to the trouble of putting them together, let alone posting them all, and I thought I was doing you a favour by keeping it simple, and screenshots/browser information etc are usually the first things you ask for. I naturally thought anything which prevents the accurate placement of aircraft on the map would be of concern.

                I'll stop wasting my time and effort reporting errors. If you don't give a shit then I wont either.

                Regards,
                Gregg
                Last edited by fungus; 2014-10-26, 13:11.
                YSSY2/T-YSSY4 [SBS-1 Basestation w/- SSE-1090 SJ Mk2 Antenna (Thanks Delcomp) ] [Uniden UBCD996T w/- 16 element Wideband Discone VHF/UHF Antenna, and tuned 108MHz-137MHz Airband Antenna] [Trialing a home-brew 1090MHz collinear antenna]

                Comment


                • Fungus, I have very clearly described how the systems works. We don't want to show all data. That is not a bug. That is how the system is designed to work. We want to be sure that the data is correct before we show it. One, two, three, four och even 1000 screenshots does not say what data was picked up, decoded or uploaded. We can only analyse the raw data, if someone claims that there is a bug. I haven't seen any indication that there is a bug, so we will not start any investigations by ourselves.

                  Comment


                  • Mike,

                    Try watching the playback I quoted and you'll see the error (I seem to be repeating myself here). You may need to drop the belligerent attitude first. Watch the Sydney area for a while and you'll see it occur repeatedly as I have. If that's the sort of 'quality' you're satisfied with I'll accept it. But, THERE IS AN ISSUE WITH THE MAP. I have my suspicions which radar it is that's causing the issue but I'm not going to put that on the forum.

                    Is 'near enough is good enough' the go here? Or do you just don't care? Random aircraft disappear on take off role and don't appear until 50-60 km's from the airport. All others appear fine. Telling me how the system works doesn't change the cold hard fact.

                    Gregg
                    Last edited by fungus; 2014-10-26, 20:28.
                    YSSY2/T-YSSY4 [SBS-1 Basestation w/- SSE-1090 SJ Mk2 Antenna (Thanks Delcomp) ] [Uniden UBCD996T w/- 16 element Wideband Discone VHF/UHF Antenna, and tuned 108MHz-137MHz Airband Antenna] [Trialing a home-brew 1090MHz collinear antenna]

                    Comment


                    • Originally posted by fungus View Post
                      Mike,

                      From what I'm seeing I don't share your confidence. I fail to see what part of 'multiple errors' regarding aircraft failing to appear on the map when they should do so (noted by the screenshots and the fact they are displaying correctly on my receiver) is not an issue for you to be concerned about, let alone so blase (that's 'unconcerned' or 'indifferent'). The reasons why and the technical aspects as to what is occurring are not for us to be able to answer since we are told nothing relating to the 'raw data' side of FR24 (afterall, I'm just a 'flyswatter' on the chat). We simply aren't all privy to it and surely cant be expected to provide such data. We cant be expected to have access to all the raw data of all the feeders in the Sydney area, that's just plain ridiculous. It simply seemed to be something that has only been occurring lately which didn't occur in the past. Thus worth noting and advising you about (or so I thought). I've got other examples, I just don't have the energy to go to the trouble of putting them together, let alone posting them all, and I thought I was doing you a favour by keeping it simple, and screenshots/browser information etc are usually the first things you ask for. I naturally thought anything which prevents the accurate placement of aircraft on the map would be of concern.

                      I'll stop wasting my time and effort reporting errors. If you don't give a shit then I wont either.

                      Regards,
                      Gregg
                      Since I also demonstrated a problem around YBBN a few days ago, it tends to go towards a pattern, and as a systems and network administrator for two decades, I can tell you developers dont like being told their wonderful code might be problematic, be it in code itself, or a configuration of - it's always the "servers" or "clients" fault, never the software.

                      Given what I posted few days back, and since that aircraft which apparently has bad corrupted data, despite it being fine and overhead of me at one point, showed fine in every aspect here, and was acceptable data to other places I feed but not to fr24, it clearly goes to pattern.

                      Comment


                      • Originally posted by Mike View Post
                        Fungus, I have very clearly described how the systems works. We don't want to show all data. That is not a bug. That is how the system is designed to work. We want to be sure that the data is correct before we show it. One, two, three, four och even 1000 screenshots does not say what data was picked up, decoded or uploaded. We can only analyse the raw data, if someone claims that there is a bug. I haven't seen any indication that there is a bug, so we will not start any investigations by ourselves.
                        Mike, if that's true, then you DO have a problem...

                        a few days ago a rescue helo - rscu511 (VH-BKV) - was showing a track stalling around the Mt Glorious region, north west of YBBN, it was attending an RTC on the mountain, it landed, FR24 after a couple of minutes resumed a track, in direct line as if the helo continued on, this path was displayed for some distance past where the helo *LANDED*

                        So its obvious your 1/2/3 feeder point system is flawed, and I note the flawed report came from an F feeder, YBSU2, if I recall correctly, so care to explain that? or dont you apply conditional testing on your own feeders, clearly, if you dont, you need to!

                        Comment


                        • Originally posted by fungus View Post
                          Try watching the playback I quoted and you'll see the error
                          Random aircraft disappear on take off role and don't appear until 50-60 km's from the airport. All others appear fine. Telling me how the system works doesn't change the cold hard fact.
                          Gregg
                          If aircraft disappear then there is no coverage. No coverage is not a bug.

                          Comment


                          • Originally posted by Ressy View Post
                            Mike, if that's true, then you DO have a problem...

                            a few days ago a rescue helo - rscu511 (VH-BKV) - was showing a track stalling around the Mt Glorious region, north west of YBBN, it was attending an RTC on the mountain, it landed, FR24 after a couple of minutes resumed a track, in direct line as if the helo continued on, this path was displayed for some distance past where the helo *LANDED*

                            So its obvious your 1/2/3 feeder point system is flawed, and I note the flawed report came from an F feeder, YBSU2, if I recall correctly, so care to explain that? or dont you apply conditional testing on your own feeders, clearly, if you dont, you need to!
                            Like I said a couple of times. We will not investigate anything without raw data. If there is no coverage, then there is no coverage. We don't do magic but flight tracking. We have the same requirements on data quality, and in some cases higher, on F-feeders compared to software feeders. That is why F-feeders seldom transmit ground data. We don't show data unless we are almost 100% confident that it is correct. And as I wrote, data in areas with weak coverage should not be trusted and not uploaded.

                            You can call it flawed or what ever you want. We have been working on improving the data quality for 6 years and we are very confident with the quality but of course errors still happen sometimes. Many users obviously fast forget how data looked like 1-2-3-4-5 years ago with aircraft jumping 10-100-1000-10000 kilometers off route, aircraft taxing around in the ocean or landing backwards. We get data from at least 20 different hardware manufacturers and 100 different software configurations that all handle the data in different way with different formats. Some decoders decodes the data in one way, other in another way. Unifying and trusting the data is far more complex than most can imagine and we have high demands on the data that is uploaded. On, two frames or 10 incomplete frames are not enough to be shown on FR24 although they maybe shown in local software.

                            Example of data errors we have more or less get rid of by not trusting insecure data

                            https://dl.dropboxusercontent.com/u/5175572/error1.PNG
                            https://dl.dropboxusercontent.com/u/5175572/ryr.PNG

                            Comment


                            • Originally posted by Mike View Post
                              Like I said a couple of times. We will not investigate anything without raw data. If there is no coverage, then there is no coverage. We don't do magic but flight tracking. We have the same requirements on data quality, and in some cases higher, on F-feeders compared to software feeders. That is why F-feeders seldom transmit ground data. We don't show data unless we are almost 100% confident that it is correct. And as I wrote, data in areas with weak coverage should not be trusted and not uploaded.

                              You can call it flawed or what ever you want. We have been working on improving the data quality for 6 years and we are very confident with the quality but of course errors still happen sometimes. Many users obviously fast forget how data looked like 1-2-3-4-5 years ago with aircraft jumping 10-100-1000-10000 kilometers off route, aircraft taxing around in the ocean or landing backwards. We get data from at least 20 different hardware manufacturers and 100 different software configurations that all handle the data in different way with different formats. Some decoders decodes the data in one way, other in another way. Unifying and trusting the data is far more complex than most can imagine and we have high demands on the data that is uploaded. On, two frames or 10 incomplete frames are not enough to be shown on FR24 although they maybe shown in local software.

                              Example of data errors we have more or less get rid of by not trusting insecure data

                              https://dl.dropboxusercontent.com/u/5175572/error1.PNG
                              https://dl.dropboxusercontent.com/u/5175572/ryr.PNG
                              seems you need to put this information on your website, so those thinking about feeding will understand why stuff vanishes, over tracks, and if they want to bother feeding you at all, why their never appears, especially if they are in a remote area since you will not trust their data, none of this is on your website, in any FAQ I've found, and its the first I and it seems many others here, have heard about it.

                              Also if you are that concerned about accuracy, why bother with MLAT since that is by very design, guesswork. Seems its ok to be inaccurate in one way, but not in others, the logic is flawed, but i'm not about to fill my disks running dump1090 in debug mode to do your homework for you, sooner or later you will see this in your area, and then maybe you will give a damn.

                              it seems discussing anything with you is pointless,we dont live on fr24 to wait for next screwup whilst in debug mode, but you have the database, you should know who sends what and when and why something's used or discarded, if it was an ongoing thing happening every hour or so, thats easy to debug and send you your precious raw data, but since you refuse to lift a finger otherwise, we are all just wasting our time and energy conversing with you.
                              and since you dont trust the data of single coverage feeders, but the other ads-b feed services do, perhaps we should just killoff the fr24 feeder, if its a waste of time, which according to above, is.

                              this ends my participation here.

                              Comment


                              • Originally posted by Ressy View Post
                                seems you need to put this information on your website, so those thinking about feeding will understand why stuff vanishes, over tracks, and if they want to bother feeding you at all, why their never appears, especially if they are in a remote area since you will not trust their data, none of this is on your website, in any FAQ I've found, and its the first I and it seems many others here, have heard about it.

                                Also if you are that concerned about accuracy, why bother with MLAT since that is by very design, guesswork. Seems its ok to be inaccurate in one way, but not in others, the logic is flawed, but i'm not about to fill my disks running dump1090 in debug mode to do your homework for you, sooner or later you will see this in your area, and then maybe you will give a damn.
                                We have been very clear with that accuracy and data quality is important to us and that we are doing a mashup of data from different sources. More data = more accuracy. I don't know any other web page out there who informs so much about how data is processed. I have not seen pages like MarineTraffic, Flightaware, PF, RB24 or any other pages giving so much information. We have also informed that the radar code shown is not correct as the data is a mashup of data from several receivers. We are confident with the data quality and by design not all data is used, but more data once again gives more accuracy. If someone says "not all data is used" we will not start an investigation to investigate something we know. We have no plans to reintroduce errors that took us years to get rid of. So I don't really see what we are discussing here.

                                MLAT has nothing to do with guessing. MLAT accuracy can be higher than ADS-B and in Europe ATC uses MLAT instead of ADS-B as it is more accurate. Do you suggest that ATC is based on guessing?

                                Comment

                                Working...
                                X