SkyAware - aircraft type "other": my plane

Hello! Here is a question falling between aircraft tracking and real world aircraft configuration. My own aircraft has a transponder connected to a GPS and this, shortly, should put out ADS-B data. There is a significant difference in how the plane shows up now, it is tracked correctly and it is clear that the GPS data is transmitted. However on my local recievers SkyAware it is displayed as “other” and lacks data for ident, altitude etc. Only ICAO and squawk is displayed. Does anyone here know what transmitted data is lacking for this to happen? I can tinker a bit with the settings but not much, there is unfortunately no config file in the transponder that I can access by Putty. :slight_smile:

What is the transponder model? What’s your aircraft tail number / Mode S address, if you’re willing to share? How are you testing the aircraft output versus your local receiver?

From your description, SkyAware is hearing - at best - only Mode S data, not full ADS-B data.

Yes, I can share that. SE-VKX/4AD978, the transponder is a Becker BXP6401 coupled to a GPSmap 495 with standard NMEA output. Testing is a bit difficult while flying but I looked at the local receiver on the phone whilst airborne yesterday and took a screenshot.

This is a bit weird, because the transponder does seem to be sending ADS-B just fine, and most receivers in the area are hearing all those messages correctly (which is why the track on the FlightAware website looks good), but specifically your receivers are apparently not hearing any of the ADS-B messages and only hear the basic Mode S messages. I don’t think I’ve seen that sort of failure mode before.

What’s your receiver hardware/software?

That seems strange. If we focus on ESMK11 which is the station I looked at it is a RBpi3 which is quite old, don’t know which version of RaspiOS is on it. AirNav RadarBox ADS-B Flightstick. The antenna is a Vinnant FE1090. But it is piaware that is the primary feeder, up to date.
My other receivers (I manage ESMK 12 (Flightstick), 18 and 19 (both Flightaware-stick) rely on dump1090-mutability as it is what is supplied for FR24 and has piaware as add-on feeding software.

This plane also has FLARM which outputs a signal with the same HEX but as far as I know that should not affect the way ADS-B receivers interpret data.

Unmaintained software. I’d suggest updating to something that is maintained e.g. dump1090-fa or readsb.


Yes indeed, but that is not on ESMK11, which runs -fa.

And that’s coming from the guy who wrote the mutability version!


Is there any possibility of Piaware/dump1090-fa filtering out non-qualified ads-b messages such as those coming from a non-certified installation as mine? I got a hint at looking into transponder SIL settings.

No, they don’t filter on SIL or other integrity/quality indicators.

1 Like

This is interesting. This is another plane with similar setup, although I know the version of transponder (also Becker BXP6401) is with another certification. I guess that writes off the option that it is my reciever setup that is faulty? Flight Track Log ✈ SE-VPF 12-Apr-2023 (EDAY-KID / ESMK) - FlightAware

Yesterday I sat down with a brand new SD-card and did a complete reinstall of my home receiver. Raspberry Pi OS Bullseye, Dump1090-FA as decoder. Didn´t change anything except setting ADAPTIVE_BURST=no to =yes. Hopefully next time weather permits flying my own aircraft will show up, at least on my own radar.

1 Like