978 Not Feeding via 1090 RPi

FlightAware ADS-B Flight Tracking
1

A few months ago I added a separate RPi and FA stick with 978 antenna. I already had a 1090 setup on its own RPi. Members were VERY helpful at the time getting my 978 set up (see here From the Top...978 Setup).

At the time, I wasn’t aware of how to set my 1090 to retrieve the 978 feed. As a result, I had two feeder stations in my profile:

image

Site 111924 was (until recently) my standalone 1090, and 124628 was my 978. I recently figured out how to configure my 1090 to fetch the 978 data and configured the 1090 RPi’s Piaware accordingly. After doing so, my 111924 site immediately updated with line items for my 978 UAT data:

image
image731×297 7.42 KB

As you can see, ADS-B UAT is showing all zeros. But it’s there, and it wasn’t there before configuring 1090 to fetch 978.

Now, if I look at my 124628 page, I am seeing my 978 data:

image
image728×290 5.68 KB

I’d like the 978 stats to be reporting under my “primary” 111924 site along with the 1090 stats. I’m assuming that since there is a separate feed to 124628 going on, the 1090 fetch is having some sort of conflict. How can I resolve the conflict, and how can I remove the standalone 978 site page under 124628?

2

(1) From your Flightaware Status page for site 111924, find your feeder-id (Unique Identifier)
https://flightaware.com/adsb/stats/user/wmccouch#stats-111924

image

 

(2) Copy-paste it on Notepad. It will be in format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

(3) In 978 Pi, do following

sudo piaware-config feeder-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  
## Replace xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx by the feeder-id of station 111924     

sudo systemctl restart piaware

 

(4) Wait for 10 minutes, then check your Flightaware Stats page for site 111924
https://flightaware.com/adsb/stats/user/wmccouch#stats-111924

 

3

What is your exact configuration?

4

On the 1090 RPi I executed the following:

sudo piaware-config uat-receiver-type other
sudo piaware-config uat-receiver-host xxx.xxx.x.x (the local IP of the 978 RPi)
sudo piaware-config uat-receiver-port 30978
sudo reboot

5

I see both 1090 and 978 aircraft reported in the stats for site 111924 starting from the 10th, so this seems to be working fine?

6

Yes, everything has been perfect since then!

7

Great!
What are the settings of 978 RPi? How did you prevent it from feeding the other station 124628?

8

I followed the instructions in your first reply in this thread. Afterwards, the 978 results started showing up under the 111924 site (along with my 1090), and site 124628 stopped reporting (as desired). A day or two later, I was able to “delete” site 124628 from my profile here within the “Site Configuration” options (it looks like FA gives you the option 24-48 hours after no data is received from the feeder.)

9

Having two feeders using the same feeder ID is a bad idea - it’ll work somewhat but some things will be confused.

10

Initially you have issued following commands on 1090RPi (station 111924)

sudo piaware-config uat-receiver-type other
sudo piaware-config uat-receiver-host xxx.xxx.x.x (the local IP of the 978 RPi)
sudo piaware-config uat-receiver-port 30978

Inspite of above settings, the UAT data was not shown on your station 111924, showing that these 1090RPi settings were ineffective in pulling UAT data from 978RPi (may be wrong local IP used in settings? Do you have a fixed local IP for your RPi? If not it may change with every reboot.)

The day you changed feeder-id of 978RPi from station 124628’s feeder-id to station 111924’s feeder-id (as per this post), the station 111924 stats started showing UAT data also.

You are actually feeding site 111924 directly from two independent piaware feeders, one piaware feeder on 1090RPi and other piaware feeder on 978RPi. Both these piaware feeders are configured to use feeder-id of station 111924.

Due to feeder-id change of 978RPi, the station 124628 stopped receiving data from 978RPi, and that is why you were able to delete it after two days.

11

Yes, the feeder ID change was the other necessary step.

With the 1090 and 978 receivers in the same physical location, it seems this situation should be considered a single “feeder site” despite two FA dongles being necessary to discriminate the frequencies separately. However, FA treated these as separate feeder “sites”, and the 978 location was relegated to the tail end of the rankings on account of how low 978 traffic is versus 1090.

When I look here: Feeder Statistics - FlightAware, of the top 50 users, eight of them have combined 1090 and 978 stats. I have no idea how many users are reporting 978 via 1090 and achieving this combined perspective, but on their feeder site stats page, you see this:

image

When looking through a list of the top 1,000 users, it seems like maybe 5% have combined 1090 and 978. Since the stats page doesn’t allow you to filter users by UAT I have no idea how this compares to the overall pool of users running a 978 feed.

Is it the case that everyone with combined 1090 and 978 is achieving this by duplicating their 1090 feeder ID on their 978 dongle? @obj previously flagged this practice as potentially causing issues (not sure what those are, maybe you can elaborate?) but so far I’ve only seen two minor glitches after making the switch. The first glitch is that my new (combined) site 111924 sometimes says this on my stats page:

image

…when in fact it’s 1090 and 978 like the other “Feeder Mode” picture above. Regardless of this, the actual 1090 position and aircraft counts seem to be reporting normally alongside the UAT numbers.

The second “glitch” is also on my stats page, here:

image

The link to the 1090 web interface is missing (it seems to come and go…yesterday they were both listed). Also, when clicking the “PiAware SkyAware978” link, it tries to navigate to the local IP of the 1090 RPi rather than the 978 RPi, so the map comes up with the message “Problem fetching data from dump978.” I can still view the dump978 map by manually navigating to the IP of the 978 RPI.
Incidentally, I’m running the 1090 and 978 FA dongles on separate RPi’s.

Overall, the desire to have combined 1090 and 978 is part vanity (wanting the stats to be aggregated for purposes of ranking - though the 978 contribution is admittedly negligible), and part tidiness when looking at my personal stats and seeing 1090 and 978 results in one perspective, rather than separate stats pages. Also, we call these “Site XXXXXX”…It seems that a “site” identity should be based solely on physical location of equipment. Especially when the 1090 and 978 antennas are 12 inches apart!

If it’s the case that the only way to achieve combined stats is to duplicate feeder ID’s, and if this causes “problems” as mentioned by @obj, then I wonder why FA has stats pages configured to give combined results like this:

image

12

Most feeders use “2 dongles in one RPi” configuration:

  • One RPi with both 1090 & 978 dongles plugged into it
  • dump1090-fa using 1090 dongle+antenna
  • dump978-fa using 978 dongle+antenna
  • piaware data-feeder, gets data from both the local dump1090 & dump978, and feeds one station.

Please see items 5 & 6 in this post

Howto : Piaware SD card image 3.8.0 Quickstart Guide

13

That’s what I get for going off of old information on running a 1090 and 978 dongle on a single RPi. Back when I went to add 978, all I could find were posts about power issues and diminished 1090 performance. A few threads were created just in the past few months that clarified the process of serializing the dongles.

14

Using single RPi with both the 1090 and 978 dongles plugged into it is the best method to feed. It gives a seamless integration of 1090 & 978 feeds. Almost everybody uses it.

  1. There are no power issues if you use an official or good power supply.

  2. There is no dimnishing performance if you use Pi3 or Pi4. I use Pi2 for 1090+978 without any performance issue.

  3. The post to serialize dongle exists from the time when the first piaware beta version with 1090+978 was released.

Which model of RPi you have? If you have Pi3 or Pi4 with an official or good quality power supply, go ahead and plug your 978 dongle in same RPi in which you have plugged 1090 dongle. You will need a good quality short length USB extender cable as there is not enough physical space to plug two dongles directly to the RPi. You will also need to serialize dongles and reconfigure piaware as per steps 5 & 6 of the QuickStart Guide.

You should then shutdown the current 978Pi to prevent it from continue trying to feed with no data.

15

As a strong advocate of not creating new threads asking questions whose answers could be found by taking the time to search, I went with what I could find. But “you don’t know what you don’t know” (me) came into play here, and despite seeing the serialization instructions as per your #3 above, I subsequently encountered other posts on the power and interference issues that left me thinking separate RPi’s were appropriate. Other threads from as recently as late February had users expressing this concern and it was duly addressed, but these were created after I had searched for answers, concluded that separate RPi’s were right, and purchased my kit for 978. I suppose other posts are out there sorting the issue that I could have encountered, but I didn’t come across them in the course of searching on my own.

Oh well, straightened out now, as always great help here (and fast too).

Working with (two) RPi 3 B+ kits:

https://www.amazon.com/dp/B07BC7BMHY/ref=cm_sw_r_cp_apa_i_rHoeFbC5GSBN2

I’ll work through this switch per instructions this weekend and advise on results.

16

No, this has never been a recommended configuration.

You have two options:

  • Run one piaware that feeds both 1090 and 978; you will have one site with combined stats.
  • Run a separate piaware for each of 1090 and 978; you will have two sites with separated stats.

In both cases you have all the usual options for how piaware fetches 1090 and 978 data (local receiver, over the network, etc)

Your original config (which pulled 978 from your second feeder into one piaware) looked fine. If it wasn’t working I’m not sure why but I can’t diagnose it now that you’ve changed the config.

Well, all the “glitches” you see are related to this. Much of the server side assumes there is only a single feeder using an ID, and it will only show data for the latest feeder update using that ID. If you have two different systems with different configs using the same ID, it’s luck of the draw which system you end up seeing and it will change randomly. So this is “working as expected” - don’t reuse feeder IDs and you won’t see these problems.

This is not the meaning that we use. A site is a single piaware instance. It is normal to have more than one site that is at the same physical location.

17

My original configuration had two separate sites; when I went down the path of duplicating feeder ID’s, and running the script from @abcd567 to point the 1090 to fetch 978, I achieved the result I wanted (and that’s my current configuration, working fine with the exception of the two minor glitches noted above). But I’m going to do away with that and avoid the feeder ID problem by following the serialization instructions covered earlier and get both 1090 and 978 dongles on a single RPi.

18

I mean the configuration that you posted in your second post in this thread when I asked for your configuration: 978 Not Feeding via 1090 RPi - #4 by wmccouch. That configuration (assuming you also had the existing 1090 configuration still in place) should have resulted in a single piaware instance / single site that collected 1090 data locally and 978 data over the network.

19

Gotchya…that’s correct, but I could only get it to work by following the feeder ID duplication instructions that @abcd567 had provided last week in addition to that script to have the 1090 pull 978 data over the network.

20

They’re doing completely different things, it’s not an “in addition to”. You have told both piawares they have the same ID. On the server side, the site stats are built based on the provided ID. So that’s why they seem to be merging. But if the ‘combined’ piaware wasn’t working correctly before, it’s still not working correctly now; the problem is just being masked because the other piaware is also feeding, separately, in a way that means it’s counted under the same site.