Site 101435 is still having issues with mlat. The FA stats page shows that mlat is not running. The piaware log shows no ADS-B data program listening on port 30005. At the same time the mlat client log shows that dump1090-fa is connected and listening on port 30005. There does not seem to be an interruption of mlat data being uploaded to FA. View1090-fa shows a continuous data stream.
You have two active connections for that site (local hostnames reported are CS3 and CS4) with the same feeder ID; this generally confuses the server-side status stuff, and the log messages you see there are probably from the other host.
Generally you should not use the same feeder ID on more than one piaware.
Is there ever a reason to use the same feeder ID on more than one live piaware?
I’m asking out of curiosity, not out of an attempt to start a war!
Probably if you have dump1090 and 978 on different Pis but want them to be shown under one station, which does not work…
That doesn’t work either.
Yes, I thought that was obvious 
No, there’s no reason to do this. If you do, data is still fed, but most of the stats and site management stuff will be confused. The feeder ID is meant to uniquely identify the particular piaware install (previously, we used MAC address, but this is not sufficiently unique and can change when you don’t want to to e.g. if swapping hardware)
Somewhere on my todo list is to ensure that there’s only one connection per feeder ID.
I think the most common cause of this is accidental duplication of the feeder ID when duplicating an existing install as a starting point for a new feeder.
CS3 is not online. CS3 was last online last year before it became a full time print server. It does not have an ADS-B radio. AFAIK the ADS-B feeding software is not running. CS4, an RPi 4B, replaced CS3 sometime in July 2019. This issue is recent. As of this morning, the logs are similar to what I posted but the stats page shows MLAT green for awhile, then red for awhile, repeat. View1090 shows lots of data. Over 400 MLAT positions were reported this morning.
Thank you obj
I was confused by the statement:
“Generally you should not use the same feeder ID on more than one piaware”.
This implied there were valid reasons to do so.
Thank you again for the clarification.
Well, I don’t know what else to tell you - we had two connections from the same (external) IP, one with a uname string containing CS4 and one containing CS3.
I’ll PM you the exact details and the reported local IPs etc.
OK, I discovered that the Pi had not been rebooted since CS4 came online. A service must have kept running even without a dongle attached. Evidently uninstalling a package does not remove running software. I rebooted CS3 and now CS4 seems to working as expected. I know very little about Linux - just enough to follow detailed instructions.
sudo apt remove piaware
That’s all that sould be necessary and it should stop it from running as well.
Actually there was a connection from CS3 with a cached feeder ID to the FA server still working long after I ran sudo apt purge piaware. A reboot took care of the issue.
Strange - the postrm script (run during package uninstall) should stop the service; not sure why that failed to work.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.