FR24 not showing my 978Mhz data while Planefinder and FlightAware do - What's up?

[RVTim]

Intro:
This week I built and went live with my ADS-B Feeds on a Pi. My primary interest and concern was that 978Mhz traffic would be displayed by the various sites. At our airport a few people have 978Mhz systems...myself I have 2 airplanes with 978Mhz systems in them. I wanted to ensure that these aircraft aren't left out of the system and alerting, just because they are 978Mhz and not 1090Mhz. Airliners are fine and all, but GA has plenty of 978Mhz equipped aircraft now, and they will only become more popular. So I built my system with 2 dongles. 1) FlightAware Pro Stick Plus, for use on the 1090Mhz band, with a 1090Mhz antenna. 2) FlightAware Pro Stick non-plus, for use on 978Mhz band since it doesn't have the built-in filter.
I did have to do a little reprogramming of the EEPROM to get unique serial numbers on them both, but otherwise they seem to work great.

The system:
I'm running the Dump1090-Mutability version of Dump1090. It is set up using the AVR-TCP type output on port 30002. I installed FR24Feed, PFClient, and PiAware. All of them use the same port 30002 method of accessing the raw data feed, and they process and send it to their respective sites. I do see many aircraft, and my receiver is located at a small airport. I often am tracking 20-40 aircraft.

What's wrong:
Of course, after getting this all up and running I had to test it out. I took a quick flight and watched my dump1090.php web page off the pi, and I instantly could pick my plane up even while taxi on the ground. I went flying at low-ish (1000' agl) altitude, to ensure I wouldn't be picked up by radar or the distant ground based receivers. We don't have good coverage at 1000' around here. When I took off, I could immediately see the plane on my locally served web server with that dump1090.php script. I could also see it on the pfclient locally served web link, AND, it showed up on planefinder's ipad app. After that test flight, I installed piaware also, and today I did another test flight.

Today's result is that right away even at low altitude, I was being picked up by my receiver, and I could then log on to my planefinder ipad app, and the flightaware ipad app, and see myself show up fine. I could NOT be seen on the FlightRadar24 ipad app. I flew towards a big city (Minneapolis) and flew near their airspace, and never once did I show up on FlightRadar24.

So, obviously my receiver is picking up 978Mhz traffic ok, or I wouldn't be seen on the ground or at low altitude, and obviously the raw data feed is good, because its being served on the same port to all 3 systems. But why is FlightRadar24 ignoring it? Is there some sort of policy against it? If so, I'll just not feed to them, because I would only want to be a provider for systems that truly want all aircraft. But in all my hours of reading and googling and forum searching, I haven't found that they do not want UAT stuff uploaded.

Can anyone give me any tips on why?


I hate asking questions because I do like forum reading. I'm experienced in Linux and have no problems with these things usually.

I do have a couple other random questions though...

1) if using the command-line "rtl_sdr" command, such as this, is the "-10" for gain acceptable? I'm just
wondering if the "-" sign in front will interfere: (I've been using -g 48 for the time being)

rtl_sdr -f 978000000 -s 2083334 -d 00001978 -g -10 - | /home/pi/dump978/dump978 | /home/pi/dump978/uat2text
(Note: this is a general question because when running the live feed I use the normal commands. I just want to know
if this is acceptable for the gain. This is just a command that dumps stuff to the screen)

2) when viewing that dump1090-mutability local web page dump1090.php, I can't seem to figure out the color code, shading code, and
size code of the airplanes. Some have solid outlines. Some are green on the chart to the right and some are purple. Some are huge
airplane icons, and some are smaller but look like jumbo jets. My plane shows as a light plane. Is there somewhere that explains the color coding and how this data is categorized?

3) there isn't any issue with having one data port 30002 serving all 3 apps, is there?

Thanks for any help you can provide on getting my 978mhz traffic to the FR24feed working.

[MrMac]

You are not saying anything about how you merge the data streams from Dump1090 and Dump978.

I'm running the Dump1090-Mutability version of Dump1090. It is set up using the AVR-TCP type output on port 30002. I installed FR24Feed, PFClient, and PiAware. All of them use the same port 30002 method of accessing the raw data feed, and they process and send it to their respective sites. I do see many aircraft, and my receiver is located at a small airport. I often am tracking 20-40 aircraft.

If you decode with Dump1090, and pick up that data on port 30002, feed that into FR24 feed, you are just sending 1090 data... ?

/M

[RVTim]

Good point, sorry. I should have mentioned that. Yes, I'm using dump978 to dump it into the port 30001 on the dump1090 app. My plane wouldn't even be showing up if it wasn't dumping into that stream. I should have mentioned it though.

I did find a thread on the forum that referenced DF18 vs DF17 messages, and that is about the only thing that I can think of that would be the issue...that FR24feed doesn't like the messages. Thus far though I haven't been able to see a sample message in text using uat2text because I've been the one out flying while generating them.

I cannot see any GBT's from the elevation of my receiver, so I shouldn't have to worry about accidentally sending retransmit messages.

[abcd567]

Dump1090-mutability: About gain -10

Question: What does gain -10 actually mean?
Answer: Enable the tuner AGC.

Question: So that is the same as having GAIN="agc" in /etc/default/dump1090-mutability ??
Answer: Yes, if you look at the init script you will see that AGC is translated to -10 and if you look at the dump1090 source then you will see that -10 turns on AGC.

-10 is a special value meaning "turn on AGC" (for ADS-B, the AGC doesn't actually give auto-gain, just a high gain. Usually AGC will behave like "more gain than max")


-10 and agc are identical, they both end up passing "--gain -10" to dump1090, see the /etc/init.d/dump1090-mutability script:

pi@raspberrypi:~ $ cat /etc/init.d/dump1090-mutability
#!/bin/sh
### BEGIN INIT INFO
.............
.............
case "x$GAIN" in
 x|xmax) ;;
 xagc) ARGS="$ARGS --gain -10" ;;
 *) ARGS="$ARGS --gain $GAIN" ;;
esac
.............
.............

For regular gains, you want a positive value in the 0..50 range (nominally in dB). It will pick the closest gain step to the value you give. If you specify any negative number (other than -10), then the closest gain is 0dB: minimum gain!

AVAILABLE GAIN VALUES:

pi@raspberrypi:~ $ sudo systemctl stop dump1090-mutability
pi@raspberrypi:~ $ rtl_test
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 1 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 4 49.6
Sampling at 2048000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
lost at least 16 bytes
^CSignal caught, exiting!

User cancel, exiting...
Samples per million lost (minimum): 0
pi@raspberrypi:~ $

[RVTim]

Thanks abcd567. Although as I'm sure you guessed, that doesn't solve my traffic not showing up issue, but, it is nice that you took the time to post that info about gain. I did a lot of searching and came across the information, but it isn't very commonly talked about. I was glad to see the actual supported gain values when I found them. I did note in testing today that if you throw a random number like 30 in, it will default back to 29.7, so that is nice that it doesn't just die when you give it a wrong value.

Now, the thing that your post didn't cover though regarding the -10 gain is this:
(These snippets are taken direct from my running processes, so see portions of the actual running commands...)

When running the 1090Mhz dongle, it's run by "dump1090-mutability" as the command:

/usr/bin/dump1090-mutability --measure-noise --net --device-index 10901090 --gain -10 --ppm 0 --fix --lat 40.89358 --lon -90.87166 --max-range 200 --net-ri-port 30001 --net-ro-port 30002 --net-bi-port 30004,30104 --net-bo-port 30005 --net-sbs-port 30003 --net-heartbeat 60 --net-ro-size 500 --net-ro-interval 1 --net-buffer 2 --stats-every 3600 --write-json /run/dump1090-mutability --write-json-every 1 --json-location-accuracy 2 --quiet

So you're correct that in this case it's called by "--gain -10" even though in the /etc/default/dump1090-mutability file it's listed as "agc".

BUT, the only reason I was curious about the "-10" working was because it isn't dump1090-mutability that calls the dongle on the 978Mhz process. That is called by rtl_sdr and then piped into dump978, which in turn passes it to uat2esnt and then sends it into the dump1090-mutability process as an input to port 30001.

On my process list, it's actually split into multiple processes, but, the long form would be like this:

/usr/bin/rtl_sdr -f 978000000 -s 2083334 -d 00000978 -g -10 - | /home/pi/adsb-receiver/build/dump978/dump978 | /home/pi/adsb-receiver/build/dump978/uat2esnt | /bin/nc -q1 127.0.0.1 30001

So my concern was that rather than the double-dash "--gain -10" format of the command, rtl_str uses single dash "-g -10". When I ran the portion of that command manually to output to the screen, a gain of -10 shows up as 0db, but if I do -g 48, it shows up as 48db. That's why I wanted to make sure it was going to actually use agc if I did a -10. I didn't know if it needed to be a 0 or positive number when called by rtl_str as the application. Here are 2 examples of what I'm talking about:

pi@PI-RADAR:~ $ rtl_sdr -f 978000000 -s 2083334 -d 00000978 -g -10 - | /home/pi/dump978/dump978 | /home/pi/dump978/uat2text
Found 2 device(s):
0: Realtek, RTL2832U, SN: 10901090
1: Realtek, RTL2832U, SN: 00000978

Using device 1: Generic RTL2832U
Found Rafael Micro R820T tuner
Exact sample rate is: 2083334.141630 Hz
Sampling at 2083334 S/s.
Tuned to 978000000 Hz.
Tuner gain set to 0.00 dB.
Reading samples in async mode...


^CSignal caught, exiting!

User cancel, exiting...

pi@PI-RADAR:~ $ rtl_sdr -f 978000000 -s 2083334 -d 00000978 -g 48 - | /home/pi/dump978/dump978 | /home/pi/dump978/uat2text
Found 2 device(s):
0: Realtek, RTL2832U, SN: 10901090
1: Realtek, RTL2832U, SN: 00000978

Using device 1: Generic RTL2832U
Found Rafael Micro R820T tuner
Exact sample rate is: 2083334.141630 Hz
Sampling at 2083334 S/s.
Tuned to 978000000 Hz.
Tuner gain set to 48.00 dB.
Reading samples in async mode...
^CSignal caught, exiting!

User cancel, exiting...


I did find, BTW, that on my Flight Stick Pro Plus dongle for the 1090Mhz side, I seem to get more traffic when using agc than other methods...although only marginally different than if I run 48db.

I wanted to try to run it the same way on the 978Mhz side, called by rtl_sdr if possible. For now I've just used -g 48 and as I mentioned, when I go flying, my plane is picked up fine.


Warning: thread creep...

This is just to post for people who are in my situation where you have 2 dongles...it took me a lot of google time to find this:

If you have 2 dongles, you may not be able to just do -d 0 and and -d 1 to call one or the other, because it would depend on which one is picked up first in bootup, or if you remove and re-insert a dongle. The safe way to always call the proper dongle is by serial number. Unfortunately, both of mine came with serial number 00001000. I found it easy to change once I found the command:


pi@PI-RADAR:~ $ rtl_eeprom -d 0 -s 00000978
Found 2 device(s):
0: Generic RTL2832U
1: Generic RTL2832U

Using device 0: Generic RTL2832U
Found Rafael Micro R820T tuner

Current configuration:
__________________________________________
Vendor ID: 0x0bda
Product ID: 0x2832
Manufacturer: Realtek
Product: RTL2832U
Serial number: 00001000
Serial number enabled: yes
IR endpoint enabled: no
Remote wakeup enabled: no
__________________________________________

New configuration:
__________________________________________
Vendor ID: 0x0bda
Product ID: 0x2832
Manufacturer: Realtek
Product: RTL2832U
Serial number: 00000978
Serial number enabled: yes
IR endpoint enabled: no
Remote wakeup enabled: no
__________________________________________
Write new configuration to device [y/n]? y

Configuration successfully written.
Please replug the device for changes to take effect.
pi@PI-RADAR:~ $ sudo reboot



pi@PI-RADAR:~ $ lsusb -v | grep Serial
Couldn't open device, some information will be missing
iSerial 3 00000978
iSerial 3 10901090

Those numbers aren't anything special, but now I can call my one process with -d 10901090 and the other with -d 00000978.
Hope that helps someone else some day that needs to change their s/n also.