No announcement yet.

Wrong altitude readings - is it a receiver problem?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Wrong altitude readings - is it a receiver problem?

    Hello all,

    What is wrong in receiver software or hardware because many light aircraft (including my N446MM) seen in FR24 are temporary indicating 0 ft altitude.
    Or is the problem somewhere else? Have a look at these examples:

    There are no similar problems with airliners which are typically using enhanced surveillance S-mode transponders.
    Is the problem related to elementary surveillance S-mode ADS-B transponders which are mainly used in light aircraft?
    Or is this problem related only to a certain type of transponder?

    Currently the following ADS-B S-Mode transponder types are typically used in light aircraft.
    - Trig TT21, TT22, TT32,
    - BendixKing KT74
    - Avidyne AXP340
    - Garmin GTX-330 with ES

    My transponder is BendixKing KT74.

    ATC is happy with my altitude although FR24 is indicating 0 ft.
    Where is the problem?

    Last edited by mohair; 2014-04-11, 11:24.

  • #2
    You have to first remember this group is made up of computer/technology/airplane enthusiasts. Not primarily pilots, aircraft engineers or ATC controllers, and the data is certainly not meant to be taken as accurate in any such official ways

    And as per FAQ, FR24 do not modify any data they are passed. They simply display it, or recover related data elsewhere matched with the information they receive IE routing based on Callsign.

    So the information is decoded from the data packet, originating from the aircraft. So if its wrong due to the different make of transponder - not being pilots of manufacturers of said equipment the fault finding as to whether it's the onboard equipment FR24 has no control over stops there. And they are not responsible for engaging the different makers simply to point out 'your data shows funny on our website'

    It also depends on the origin, some data is passed on by other networks. You have not listed any of the receivers that were in contact at the time or producing the 'wrong data'.

    So no-one will be able to rule out if it is bad reception on behalf of the station uploading, or 3rd party data FR24 have no control over without further info. I myself often see full ADSB signals show 0 altitude on outter reaches of my range until there is further squitters received to fill in the blanks - it may well be a case of that, or overlapped sources for the information which have not updated correctly. (FAA vs PP vs MLAT)
    Posts not to be taken as official support representation - Just a helpful uploader who tinkers


    • #3
      IIRC, at least in the US, ATC does not use DF17 for altitude purposes, so they would be happy as long as your transponder sends out the basic mode-S (DF4?) message with correct altitude. It's difficult to say where the problem is (could be receiver reception issue, for example) or you may have an issue sending out altitude info in the DF17 message only (that's what FR24 displays). Your best bet would be recording "raw" data (bits) probably from on-board the airplane then see if there's really an issue with your DF17 messages vs simply those not being properly received by an antenna on some enthusiast's roof.


      • #4
        Originally posted by Oblivian View Post
        You have to first remember this group is made up of computer/technology/airplane enthusiasts. Not primarily pilots, aircraft engineers or ATC controllers, and the data is certainly not meant to be taken as accurate in any such official ways...
        I understand that FR24 is not intended for official use but it would be nice to see correct information also from light aircraft. In the near future there will be more and more light aircraft which are equipped with ELS level ADS-B transponders.


        • #5
          mohair, This problem needs to be analysed a slice at a time

          If i were in your position - I would playback some of the more recent flights and when they show zero altitude make a note of the 'radar' supplying the data to FR24

          then contact support with the data of the Date and UTC time of the events, the radar code (especially if its an 'F-' radar or a 'T-' radar) they can look at the raw uploaded data to try to work out what could be wrong.

          They only keep the raw data for a short period of time - a few days at the most, so no point in sending info relation events to two weeks ago.

          FR24 control the F- radars - so will be very interested if they are supplying faulty data

          The T- radars are individual privately owned radars feeding FR24 - FR24 could notify T- radars they are feeding incorrect data

          N- radars are networks of other feeders and it would be more difficult to find the problem.

          Support should be able to then work out if it's a receiving problem (most likely) or a data aggregation and display problem.

          If it's a receiving problem and the radar flavour causing the issue is identified (dongle, beast, windows, linux, etc) then there is more work.


          • #6
            Thanks for your advice.


            • #7
              For what it's worth.

              I have seen light aircraft at low altitude that were traced by T-EKAH3 (me, DVB-T dongle on Windows PC with RTL1090) and F-EKAH1 (FR24 controlled) alternating between the two. When ever the T-receiver was feeding (apparently - I understand that the radar code cannot be trusted) altitude was given, but when ever the F-receiver was 'in charge' altitude was 0 ft.
              That led me to the conclusion that the F-receivers have a software/firmware glitch or have a higher data quality standard and therefore filter out 'unreliable' altitude readings.


              • #8
                Tnx Kpin, that is an interesting finding!


                • #9
                  Hi all,

                  I have tried to learn how these altitudes are transmitted in DF17. In this mohairs N446MM case aircraft is transmitting it's altitude
                  using 100 ft resolution. So when looking raw data and binary representation so called Q-Bit (Message bit 48) is zero, which means that MODE C like
                  altitude encoding is used instead that binary for 25 ft increments (Q-bit is 1)


                  One raw N446MM originating 112-bit DF17 frame received at my site F-EFHK2 (FR24 Box). Aircraft flying in that case at 2000 ft.

                  12-bit altitude field taken from that raw message is:

                  8-bit (Q-Bit) in that case is ZERO

                  Sequence used to encode altitude when Q-bit is zero in DF17 message:

                  C1 A1 C2 A2 C4 A4 B1 ZERO B2 D2 B4 D4
                  0 0 1 0 0 0 1 0 0 0 1 0

                  MODE C representation:

                  A1 A2 A4 B1 B2 B4 C1 C2 C4 D1 D2 D4
                  0 0 0 1 0 1 0 1 0 0 0 0 = 2000 ft

                  Just wondering would there been anything which could sometimes lead into different altitude readings in situations when that 100 ft resolution is in use?
                  I think that 25 ft is almost in use for all commercial traffic etc. but these new ELS ADS-B setups could maybe also use lot of that 100 ft increment.

                  Anyway, I have gone thru my FR24 box received raw DF17 packets from that one N446MM flight on 5.4.2014

                  and atleast all DF17 frames received indicate valid altitudes when trying to decode them using different software options (VRS, Globe-S mini etc.) available nowadays.

                  Edit: Data was mostly coming from F-EETN2 and change from valid altitudes to zero happened (around 14:52 UTC) when same F-EETN2 was delivering data.

                  Last edited by laxlou; 2014-04-14, 14:25.


                  • #10
                    Laxlou, thanks for your precise investigation.

                    If the problem is related to 100 ft resolution encoding that explains why commercial aircraft are indicating correct altitude - they are encoding altitude in 25 ft increments. On the other hand this means that the problem may not be related for all light aircraft because they can also have an altitude encoder with 25 ft resolution.

                    Additionally as Kpin wrote the suspected software bug may be in F-receivers only. If this is true who could help in finding and repairing the problem?

                    Edit: I checked my findings of 0 ft incorrect altitudes. They are all encoding in 100 ft increments when they indicate correctly. So quite probably the problem is related to the 100 ft encoding increment.

                    Last edited by mohair; 2014-04-14, 21:03.


                    • #11
                      This is good analysis. I am actually watching one such issue right now with a Cessna.. While F- feeder is providing data the altitude is 0, but as soon as it switched to my feeder it showed correct altitude (5,000 ft).. and then lost it again when F- took over again.. There does not appear to be an issue with "raw" data sent by aircraft's transponder.


                      • #12

                        White/green color of the track is as local F- feeder and my feed are switching over who's providing the data -- green while I am feeding (with correct altitude) and white for 0ft altitude when F- was feeding the data for same airplane.


                        • #13
                          Similar findings here. See the N5549A Cessna T210N. From left to right:
                          F-receiver incorrect 0 ft (White), T-receiver correct 6700 ft (Green) and F-receiver incorrect 0 ft (White) again.

                          N5549A-F-RX-1.jpg N5549A-T-RX.jpg N5549A-F-RX-2.jpg

                          Must be something wrong when FR24 is using F-receiver and transponder is encoding in 100 ft increments.
                          Last edited by mohair; 2014-04-15, 13:28.


                          • #14

                            It would appear the second portion of my original post after requesting more information has turned out be the possible reason. Which is why support etc often ask for receiving station information to assist diagnosing anomalies (opposed to asking 'where is the problem' and listing particular transponder types )
                            Posts not to be taken as official support representation - Just a helpful uploader who tinkers


                            • #15
                              3. Mode-S
                                a. Interrogated by ground station
                                    1. DF0 (56 Bit)
                                        • ACAS (general)
                                        • TCAS (as one sort of ACAS)
                                    2. DF4 (56 Bit) rollcall reply: altitude (100ft resolution)
                                    3. DF5 (56 Bit) rollcall reply: squawk
                                    4. DF11 (56 Bit) transponder capabilities
                                    5. DF16 (112 Bit) never observed
                                    6. DF20 (112 Bit) rollcall reply: altitude (25ft resolution)
                                        + BDS registers (Mode-S enhanced surveillance EHS)
                                    7. DF21 (112 Bit) rollcall reply: identity
                                        + BDS registers (Mode-S enhanced surveillance EHS)
                                b. Squitter mode frames (independently transmitted)
                                    1. DF11 (56 Bit) with InterrogatorID set to zero
                                        Used to get transponder capabilities without Allcall and Rollcall
                                    2. DF17 (112 Bit) 1090 Extended Squitter contains ADS-B data (position, heading e.g.)
                                    3. DF18 (112 Bit): same as DF17 but from ground traffic
                              So does this mean some equipment - when interrogated - responds with a DF4, other equipment responds with a DF20, and one of those responses is not always being decoded correctly?

                              If so what radars do decode it correctly and what don't?