Announcement

Collapse
No announcement yet.

Flightradar24 Feeder Chat

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

  • 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


                      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/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


                          • There are a couple of points:
                            1. Most people are not too interested in the altitude and speed of an aircraft - just where it is on the map
                            2. It should be possible even with incomplete data to see if the data that has been uploaded by a single station is credible - is the position reported reasonable for the aircraft (by make and model, flying at that altitude) compared to prior positions reported. A B752 at 5000ft is only likely to be within - say - 10km of the position it was in 10s ago type thing.

                            The maths would be a pain to work out but if doing Pythagoras and you're only interested the approximate magnitude of the answer - don't do the square root calculation (divide lots of compute) square the other side of the calculation instead (multiply is faster). or even easier just have a lookup table. Its a (B75,b73, a32, a33, a34, etc) 10s since last position - whats the square of the maximum distance it could have travelled ... is the position given within that range?

                            Comment


                            • The first and last data is often the the source for many errors as signal is weak. If altitude is missing what says that position is correct?
                              This is a very common when a DVB-T stick feeds with some software https://dl.dropboxusercontent.com/u/5175572/error1.PNG
                              You get a first position 100km from the airport and then your suggestion " is the position reported reasonable for the aircraft (by make and model, flying at that altitude) compared to prior positions reported." or "whats the square of the maximum distance it could have travelled ... is the position given within that range?" fails as first position was wrong and you would never get back to correct location again. That is why we are very keep on verifying the first position data.

                              I have now explained how this work and we have no intentions to reduce the data quality. We get far too much complains on the data quality that we want to take any steps back in development. We are instead putting our energy on keeping improving the quality. We can never make everybody satisfied, it's just not possible, but we are confident that better quality is the right way to go.

                              Comment


                              • Originally posted by Mike View Post
                                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?
                                Really?

                                I think you'll find that MLAT is used as a lower cost alternative to traditional secondary surveillance radar. I've never seen any evidence that it is more accurate than ADS-B but am happy to be proven wrong.

                                However, the current discussion is whether usable data is ignored to the detriment of tracking a flight on FR24.

                                I appreciate FR24 has become a major player in flight tracking and cannot investigate every reported issue but maybe it should look at some, if only to identify why there's a mismatch between the local data and that shown on FR24.

                                From what I see posted, a data sharer usually reports discrepancies to help FR24 and not pick a fight. But there's an emerging trend to dismiss such reports out of hand together with anyone who questions or debates with the FR24 team. The last time a thread was locked and I hope this doesn't happen here.

                                It would be a sad day if the sharers who breathed life into FR24 turn off their data feeds just because they are being ignored or their views dismissed without justification.
                                Mike


                                www.radarspotting.com

                                Radarspotting since 2005

                                Comment

                                Working...
                                X