978 Not Feeding via 1090 RPi

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

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.)

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

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

I dont think he made any changes to 1090RPi config, it should be still there. The only change in config he made was in 978RPi config by changing its feeder-id and that is all.

Most likely the reason of 1090RPi config not working is as in my post quoted below. I am still waiting for @wmccouch’s reply about fixed local ip of RPi.

Took a little while to think about everything, and appreciate your thoughts both @abcd567 and @obj. I think I have it figured out.

This must be what’s happening. My very first step in trying to get combined reporting was to run this script on the 1090:

Initially I was encouraged because my 1090 feeder site page added a line for the UAT position and aircraft counts right after I ran the script. But it reported nothing under the count, so I came back here and created the first post on this thread, to which @abcd567 replied with the suggestion of duplicating the 1090 feeder ID on my 978 RPi (see first reply to my original post). When I did the feeder ID duplication, my 978 numbers started populating on the 1090 stats page. So I thought everything was solved. In hindsight, @obj is right, that initial fetch script isn’t doing anything for me right now, the combined results are solely on account of the duplicate feeder ID.

Completely correct explanation. The 978 RP is on a fixed local IP; however, my 1090 RPi is connected via ethernet which runs to a Netgear unmanaged switch (all Cat-6 jacks in the house are connected to it). The 978 RPi is connected via WiFi to a router that itself is connected to the network switch. The router is issuing device addresses on a 192.168.x.x basis; however, devices connected directly to the network switch are addressed as 10.0.0.xx. It’s possible that the initial fetch script didn’t work because that 1090 RPi is working on a different subnet than the 978. While on the topic though, can you confirm that port 30978 is correct for the script?

Incidentally, the 1090 was on WiFi originally, but a while back I changed the network password. It was easier to just plug the RPi into a nearby Cat 6 jack than to pull the SD card and update the WiFi configuration in that text file in PiAware. I wasn’t aware of a way to update the wifi network settings remotely via putty.

Ultimately I’d prefer a single RPi running both dongles, so I’ll be following those instructions provided earlier. It’ll be further incentive to finish building a 15’ tall PVC antenna mast I designed for my roof to which I’ll be mounting both antennas. Got up on the roof last two weeks ago to scope it out and nearly had a Clark Griswold happen.

What script?

30978 is the raw data port that piaware needs to connect to, yes.

Look at the piaware logs if you have problems. They’ll tell you about any failure to connect.

These initial instructions from @abcd567:

Oh. That’s just config, not a script. You could equivalently just edit /boot/piaware-config.txt by hand.

On your 1090 RPi give this command, and wait for few minutes till some UAT traffic appears on your Skyaware978 map.
(Replace xxx.xxx.xx.xx by local IP of 978 RPi)

sudo nc xxx.xxx.xx.xx 30978

What do you see?