Yeah it’s the missing location then, i don’t even need to look at the json.
Add the location to /etc/default/combine1090 if you are using that or /etc/default/dump1090-fa if you are using that and combine1090 only for forwarding the data.
You can add it for example like this:
DECODER_OPTIONS="--lat 50.1234 --lon 10.1234 --max-range 320"
You’ll need to restart either the combine1090-dump or dump1090-fa service.
Done.
Thanks a lot .
I’ll have to check in the morning whether it is working the next departure is scheduled in 4 hours 
Just to clarify that is no filtering you are hitting there.
Ground positions require a reference position, if no prior aircraft position is known, the receiver position is used because receivers can’t receive aircraft on the ground for very far.
(the assumed maximum range for aircraft on ground is 80 nmi i believe)
So when a plane lands, you have a previous position as reference, but when it’s taxiing for takeoff you don’t.
Thanks a lot. I can confirm that it seems to be working now.
If the maximum range for ground positions is 80 NM, does that mean when I use a “net-only” instance and feed in from multiple receiver sites (that are further away than 80 NM from the reference point) the ground positions will not be shown? or is that regardless of the distance to the reference point.
On another note: You can use “zIndex: [int]” in ol to give your layers a different level and define what layers should be shown above others. Additionally you can use “decluttering: true” to hide layers that overlap, which changes depending on the zoom status.
Regards,
Dennis
They will be in a completely wrong location, but if that happens you will notice.
Or you won’t notice because you have defined --max-range and they get filtered by that after being wrongly placed somewhere completely else on the globe.
Ground positions are a real limitation for net-only aggregation.
So? I’m aware of those features.
Edit: decluttering the track labels probably doesn’t hurt.
Don’t think i’ll use it for anything else though.
It’s actually 45 degrees latitude/longitude; so long as you never see aircraft that are more than 45 degrees away from any of the receivers that make up the aggregated data, any of those receiver location will work OK. i.e. it will stop working if you have a pair of receivers that are more than (45 degrees - 2 * maximum receiver range) apart. That’s quite a large distance so you may be OK.
(a pair of surface position messages decodes to 8 possible locations, each separated by 90 degrees lat/lon; the configured receiver location or a recent aircraft position is used to pick the nearest of those 8)
My UAT stopped reporting traffic around October 31st. Any idea what I can do to troubleshoot? Thanks, Will
Hello Wiedehopf,
after reinstalling all my feeders I installed this one as well.(as I did before). It works like a charm, thank you very much for this great add-on.
Thanks,
Dutchyb
This sequence repeats every hour or so on the log. I have no clue what any of it means (other than failure is not good!!)
Dec 20 12:56:16 piaware dump978-fa[26543]: Caught signal 15, exiting
Dec 20 12:56:16 piaware systemd[1]: Stopping dump978 ADS-B UAT receiver…
Dec 20 12:56:16 piaware systemd[1]: dump978-fa.service: Main process exited, code=exited, status=1/FAILURE
Dec 20 12:56:16 piaware systemd[1]: Stopped dump978 ADS-B UAT receiver.
Dec 20 12:56:16 piaware systemd[1]: dump978-fa.service: Unit entered failed state.
Dec 20 12:56:16 piaware systemd[1]: dump978-fa.service: Failed with result ‘exit-code’.
Dec 20 12:56:17 piaware systemd[1]: Started dump978 ADS-B UAT receiver.
Dec 20 12:56:17 piaware dump978-fa[9283]: raw-port: listening for connections on 0.0.0.0:30978
Dec 20 12:56:17 piaware dump978-fa[9283]: raw-port: listening for connections on [::]:30978
Dec 20 12:56:17 piaware dump978-fa[9283]: json-port: listening for connections on 0.0.0.0:30979
Dec 20 12:56:17 piaware dump978-fa[9283]: json-port: listening for connections on [::]:30979
Dec 20 12:56:17 piaware dump978-fa[9283]: Detached kernel driver
Dec 20 12:56:17 piaware dump978-fa[9283]: Found Rafael Micro R820T tuner
Dec 20 12:56:18 piaware dump978-fa[9283]: Reattached kernel driver
Dec 20 12:56:18 piaware dump978-fa[9283]: usb_claim_interface error -6
Dec 20 12:56:18 piaware dump978-fa[9283]: Detached kernel driver
Dec 20 12:56:18 piaware dump978-fa[9283]: Found Rafael Micro R820T tuner
Dec 20 12:56:19 piaware dump978-fa[9283]: Exact sample rate is: 2083333.135571 Hz
Dec 20 12:56:19 piaware dump978-fa[9283]: [R82XX] PLL not locked!
Dec 20 12:56:19 piaware dump978-fa[9283]: SoapySDR: using manual gain 25.0 dB
Dec 20 12:56:19 piaware dump978-fa[9283]: SoapySDR: using stream setting buffsize=262144
Dec 20 12:56:26 piaware dump978-fa[9283]: [::]:30978: accepted a connection from [::1]:53486
Dec 20 12:56:46 piaware dump978-fa[9283]: [::]:30978: accepted a connection from [::1]:53528
Looks like you’re just not receiving anything and piaware restarts dump978-fa because of it.
You can check the piaware log.
So on the software side everything is working, either there are no planes around or you are having a problem with the antenna or the coax to the antenna.
Thanks. Should be plenty of planes. Just stopped receiving as of 11/1. I removed the 978/1090 filter and started up again.
Are you using serials for the SDRs?
Also please post the piaware log as well just to make sure that’s the reason dump978-fa is being restarted.
Im sorry maybe im offtopic or the answer is not related with the post, thanks for your patient,
I was runing TAR1090 (Excelent work by the way) For the last months with no problems, but recently it stop working (when i try to acces the IP in my browser it stays as it was loading) so try to update and nothing happend so i uninstall and then try to install again and i get this message:
sudo bash -c "$(wget -q -O - https://raw.githubusercontent.com/wiedehopf/tar1090/master/install.sh)"
bash: line 59: cd: /usr/local/share/tar1090/git: No such file or directory
unzip: cannot find or open master.zip, master.zip.zip or master.zip.ZIP.
Unable to download files, exiting! (Maybe try again?)
All the rest of my system is working fine, “dump1090-fa” is runing fine with mlat… also a cople of other feeds installed on the pi are working good.
Thanks for your help
That really shouldn’t happen.
I suppress some output there, let’s see why this command fails:
sudo git clone --depth 1 https://github.com/wiedehopf/tar1090 /usr/local/share/tar1090/git
My guess would be that your sd-card has failed or you have no more free space or something along those lines.
The result of runing the comand is the next:
Inconsistency detected by ld.so: dl-version.c: 205: _dl_check_map_versions: Assertion needed != NULL’ failed!`
I think that its one of that errors that means the sd card has fail, but its strange that its the only problem i have on the sistem today, if you think that´s necesary a fresh install with a new sd card… Exist any toturial to get a backup or clone data of graphs1090?.
Thank you
Not really.
It’s not that complicated though.
Backup this folder:
/var/lib/collectd/rrd/localhost/
I’m not exactly sure how you would do that on Windows.
Probably with FileZilla using the SSH/SCP protocol.
On the new card copy the localhost folder to /tmp using FileZilla again.
Then do this:
sudo systemctl stop collectd
sudo mkdir -p /var/lib/collectd/rrd/
sudo cp -r -T /tmp/localhost /var/lib/collectd/rrd/localhost/
sudo systemtl restart collectd
I’ve put these rough instructions in the github readme as well:
GitHub - wiedehopf/graphs1090: Graphs for readsb / dump1090-fa / dump1090 (based on dump1090-tools by mutability)
RPi to RPi is using the same architecture.
This looks like bad sd-card corruption, so i’d recommend buying a new sd-card.
Can be other things i guess, so a reimage might be sufficient.
Good opportunity to use Raspbian Buster Lite as a base for the system if you aren’t already!
(that’s what i’d recommend anyhow)
I have the backup of /var/lib/collectd/rrd/localhost/ from my Pi3B+
I can see that the above instructions are simply copying the old backups into place and restarting.
Is there a relatively straightforward way I can restore the data and combine it with the existing new data from the Pi4 so that when I view the history, I get everything from before, plus the new stuff?
Effectively merging the rrd files from the old Pi with the month of data from the new Pi.
It’s a bit more involved.
You’d have to run rrdtool create and specify a template and 2 source rrd files.
…
Why don’t you people do this when creating the new RPi …
Anyhow, update to the new version and do this:
sudo /usr/share/graphs1090/rrd-integrate-old.sh /tmp/localhost
This is assuming you copied the old database to /tmp
