(I verified that md5sum operates on dereference source, not the symlink itself.) I cannot tell why there is one more config javascript-alias.conf on fabian64 (or why it is absent on piaware even under conf-available/). But this was an old one and a simple one.
Many thanks for your advice. I successfully moved from Stretch to the latest version of Buster. The map now has the ability to show flight numbers on the map as well as work with filters. Interestingly the map is still showing " 5.0-bp09+1"
Updated, but seems to be about the same as it was before. For you next upgrade/update, have you considered improving the aircraft type identification? The main reason I close my piaware window down and go to virtual radar is 90% of the time aircraft type=NA. Then it’s 5 clicks and 2 other webpages just to see what I’m looking at, while flight radar 95% of the time pulls up the aircraft type and even a photo when you select the target. Making the interface and experience better for the folks who are helping feed your data would seem to be a good idea.
When I check piaware-status, it always says dump978 is producing data on localhost:30978.
When I check my Piaware Status (version 5) page on the web, it indicates, correctly, connected to UAT receiver, but no recent data seen. Given that it’s 11:30 pm EDT, that is what is expected. Checking graphs1090: Performance Graphs, it also indicates my station has not seen any UAT aircraft in over 2 hours. Again, expected this time of the night.
Everything looks the same as before when running the command piaware-status except for the dump978 is producing data on localhost:30978 message is constant.
PiAware ADS-B UAT client (faup978) is running with pid 30539.
~
~
Local ADS-B UAT receiver (dump978-fa) is running with pid 30412.
~
~
dump978-fa (pid 30412) is listening for UAT connections on port 30978.
~
~
faup978 is connected to the ADS-B UAT receiver.
~
~
dump978 is producing data on localhost:30978.
Checking the gear icon on my user page, this is the most current message concerning 978:
[2021-03-21 23:36 EDT] 18491 msgs recv’d from dump978-fa (0 in last 5m); 18491 msgs sent to FlightAware
The last time any messages were sent, 55 minutes ago, one(1). Prior to that an hour and 55 minutes ago:
[2021-03-21 22:41 EDT] 18491 msgs recv’d from dump978-fa (1 in last 5m); 18491 msgs sent to FlightAware
[2021-03-21 21:41 EDT] 18490 msgs recv’d from dump978-fa (28 in last 5m); 18490 msgs sent to FlightAware
So my question is whether i am truly getting a dump978 status with the piaware-status command if it says I’m producing data when in fact i’m not? Or has the behavior changed just to indicate that all is well and connected. Previously, it would indicate that i’m not producing data. Thanks for any advice!
If I haven’t fired up virtual radar, that’s what I do. It’s just slow and clunky, especially if you are wanting to quickly identify a few aircraft. Maybe it’s just me, but for watching aircraft some of the primary things I am interested in is who/what is it.
This is normal. It’s checking that dump978 is responsive, not actually checking for off-the-air data.
(This behaviour did change in 5.0 as dump978 now always produces a metadata message on initial connection)
Could JS interpretation be temperamental in browser? Or maybe two URLs using same JS in one browser will override each other? After meticulous verification that there is no discrepancy in lighttpd configs between the two, I opened the same URLs on another Mac. The behaviors reversed: piaware behaves 5.0-like (i.e., with warning), while fabian64 is now a 4.0-5.0 hybrid, with no warning in old /dump1090-fa/ interface. The two Macbooks run the same version of MacOS, same version of Safari. The only difference is in hardware.
Could be possible, with the upgrade the config of dump1090-fa was overwritten, because I said yes on the questions asked, so I had it to set again it can be a different value now.
I have setting of 43.9 now, it’s possible that it was 44.5 before
So, I did some deeper digging and walked through issues with lighttpd and dump1090-mutability. Leveraging a few notes from wiedehopf posts in GitHub was able to rerun the automatic install for dump1090 fa. Rebooted and life is good again. Thanks guys…
No good place if it’s an piaware image.
Otherwise /etc/default/dump1090-fa.
If you need a somewhat complete guide to set up the RPi without using the piaware image, give this one a go: Raspbian Lite: ADS B receiver · wiedehopf/adsb-wiki Wiki · GitHub
readsb will auto-detect single core and reduce CPU usage, using dump1090-fa you’ll have to use the option mentioned, not sure how the CPU usage on an rpi zero compares exactly between the two decoders.
