Mode-A/C used by FlightAware?

I am using Piaware and a Mode-S Beast receiver. I have the option of configuring the Beast to send Mode-A/C reports to the Pi. I can see the reports locally, but was wondering if FlightAware uses them for any purpose. They are of little interest locally (except for “Beamfinder” fixes in PlanePlotter), so I would rather disable them at the Beast to reduce CPU loading on the Pi if they are not used by FlightAware.



they don’t according to Oliver @obj
I was looking for the thread but unable to find it.

When I have turned on temporarily the A/C decoding, the local message rate almost doubled, but the reported one on the FA web page remained unchanged.
So I would say they don’t use them.

Thanks for the info. I’m switching it off tonight.

Thanks! I’ll leave it switched off.

There are DIP switches in the Beast receiver, one of which disables Mode A/C decoding.

I use the following lines in my initialization script to software-override the hardware switch settings, as needed. See the last entry for the Mode A/C software switch:

      #DIP switch override settings - set by uncommenting selection as per PlanePlotter recommendations

      #To enable AVR output format, DIP switch 3 off
      #sudo echo -e '\x1a\x31\x63' > /dev/ttyUSB0
      #To enable Binary output format dip switch 3 on
      sudo echo -e '\x1a\x31\x43' > /dev/ttyUSB0

      #To disable DF-11/17 only filter, DIP switch 4 off
      sudo echo -e '\x1a\x31\x64' > /dev/ttyUSB0
      #To enable DF-11/17 only filter, DIP switch 4 on
      #sudo echo -e '\x1a\x31\x44' > /dev/ttyUSB0

      #To disable MLAT timestamp, DIP switch 5 off
      #sudo echo -e '\x1a\x31\x65' > /dev/ttyUSB0
      #To enable MLAT timestamp, DIP switch 5 on
      sudo echo -e '\x1a\x31\x45' > /dev/ttyUSB0

      #To disable CRC check, DIP switch 6 on
      #sudo echo -e '\x1a\x31\x46' > /dev/ttyUSB0
      #To enable CRC check, DIP switch 6 off
      sudo echo -e '\x1a\x31\x66' > /dev/ttyUSB0

      #To disable DF-0/4/5 filter, DIP switch 7 off
      sudo echo -e '\x1a\x31\x67' > /dev/ttyUSB0
      #To enable DF-0/4/5 filter, DIP switch 7 on
      #sudo echo -e '\x1a\x31\x47' > /dev/ttyUSB0

      #To disable RTS handshake, DIP switch 8 off
      #sudo echo -e '\x1a\x31\x68' > /dev/ttyUSB0
      #To enable RTS handshake, DIP switch 8 on
      sudo echo -e '\x1a\x31\x48' > /dev/ttyUSB0

      #To disable 1 bit forward error correction, DIP switch 8 on
      sudo echo -e '\x1a\x31\x49' > /dev/ttyUSB0
      #To enable 1 bit forward error correction, DIP switch 8 off
      #sudo echo -e '\x1a\x31\x69' > /dev/ttyUSB0

      #To disable Mode A/C dip switch 10 off
      sudo echo -e '\x1a\x31\x6a' > /dev/ttyUSB0
      #To enable Mode A/C dip switch 10 on
      #sudo echo -e '\x1a\x31\x4a' > /dev/ttyUSB0


You can do it easily from beastsplitter too.

Correct, piaware does not use Mode A/C. The A/C config options in piaware come from some work done to support/improve A/C in dump1090-fa & mlat-client while investigating Mode A/C multilateration, but that project didn’t proceed.

1 Like

FWIW, if you are using beast-splitter (or a piaware sdcard image, which also uses beast-splitter), it reconfigures the Beast as needed, and by default it’ll only turn on the A/C setting if a client explicitly asks for A/C. Or you can pass --force j to force that setting to off (see GitHub - flightaware/beast-splitter: Utility that distributes Mode-S Beast output to multiple clients for a full list) regardless of what clients ask for.

Thanks for that in-depth explanation.

I am using an older Mode-S Beast solution using stock full Raspbian, Piaware, two invocations of modesmixer2, and the PlanePlotter sharing program ppup1090. A script in /etc/init.d sequences everything, except Piaware, which syncs up to the setup eventually.

First the Mode-S Beast switch overrides run in the script, as above.

Then the first instance of modesmixer2 runs to supply the regular dump1090 Beast output on port 30005 (although dump1090 itself is never run):

modesmixer2 --inSerial /dev/ttyUSB0:3000000:hardware --outServer beast:30005

I then start the Planeplotter sharing program, referencing the local IP of my Planeplotter PC:

ppup1090 --quiet --net-pp-ipaddr

Finally, I start the last instance of modesmixer 2 which combines the MLAT positions from Piaware from port 30104 with my receiver data on port 30005 and makes the combined stream available to Planeplotter or other program on port 30015. I also start the modesmixer2 web server, which also displays the combined streams/

modesmixer2 --inConnect localhost:30005 --inServer 30104 --outServer beast:30015 --web 8080 --location 41.xxxxxx:-88.xxxxxx

A bit complex, but allows displaying MLAT positions on Planeplotter while still servicing Planeplotters internal sharing system, allowing the Pi to act as a Planeplotter ground station. The second modesmixer2 instance prevents polluting the pseudo-dump1090 stream on port 30005 with MLAT data before feeding to Planeplotter’s sharing servers.

I can connect Planeplotter to port 30005 to see the output of only my receiver or port 30015 to see the combined receiver/MLAT feed, or even port 30105 (from Piaware) to view MLAT-only positions. Planeplotter recognizes the DF18 MLAT messages from Piaware and color codes the MLAT icons white on its display. Local receiver positions are yellow.

For more details:

I needed to rebuild this all from scratch as I recently lost my SD card after 3 years of service. My image backup did not include Piaware. The latest Piaware requires Raspbian Stretch to install and my image used Wheezy. Painful getting it back on-line, but all good now.

I use a homebrew GPS-disciplined NTP server for timing reference. I had to disable the odd NTP client that came on the latest Raspbian distro and install the proper NTP daemon, pointed to my server.



Note that FlightAware uses the timing within the dongle and never uses NTP. There is an internal clock in most dongles.
The delay across USB is not consistent.

FYI, my Beast and Radarcape receive about 6000 packets per second (yes per second) when I enable Mode A/C. I live in NYC with lots of radars and traffic. Without Mode A/C in is only 1800 packets per second. I am only 60ft AMSL so it is probable worse with those that have higher antennas.

Thanks for the clarification. I’m using a Mode-S Beast, but I think your comment about internal timing still applies. Interesting that Planeplotter requires a stable NTP clock source for its network MLAT functionality.

I see similar message rates with and without Mode A/C in the Chicago metro area with roof co-linear antenna, bandpass filter and LNA.



Yes, The Mode S beast has an internal clock and it is used.
I forgot to mention that I also use an amp and cavity filter on my devices (Mode S Beast, Radarcape, Airspy and RTL-SDR dongles)

Did you buy different ones so you can experiment with them to see if they have similar/better results?

1 Like

The no-name generic dongles use a basic crystal oscillator.

The RTL-SDR Blog v3 dongle uses a 1ppm TCXO.

The FA Pro+ uses a 0.5 ppm TCXO.

Both the v3 and Pro+ should be stable enough under normal conditions.

Yes. The FA pro plus is the best value for money.
SDR-RTL V3 if you want to use an external amp/filter.
My location has so much noise, I have to use a cavity filter on the outside(Antenna side) of the amp/filter.
I also use the DPD antennas for my main feeds. FA antennas for the others.

1 Like

For the utility of a TCXO - I have calculated and I think that the Doppler deviation for a plane passing above head can be as high as 2 ppm (df/f=2v/c).

Shift in the carrier frequency is not really a big deal for ADS-B since the signal is fairly wideband - a 1-2kHz shift in a 2MHz-wide signal doesn’t matter at all. The transponder specs allow quite a lot of variation here anyway.

The benefit of a TCXO is more that it’s driving the sampling clock as well as the tuner, and sampling stability is important for mlat timing.

This is why no-name generic dongles, under reasonable room conditions, work for ADS-B whether the ppm is adjusted or not.

Could not have said better myself.:wink:

@obj - What’s the receiver that you are using inside the FlightFeeder? Is the FA Stick Pro?

Yes, the FF Orange uses a prostick.