You have probably updated.
If a change of mine messes with the script for saving the history the update will restart the service.
The history is saved in memory, the run directory for that service.
So restarting the service deletes that data.
I usually try to avoid that, but wanted to change some stuff.
So most updates won’t behave like this.
You could also update only manually and not every night 
1 Like
Yup, sure have.
That’ll be it, thanks.
You know me too well 
I like to be up to date.
Apart from verifying range with ?pTracks, some interesting KATL Arr/Dep traffic on the three runways and also KPDK on the NE of Atlanta.
The crontab entry for these runs at 23:20, I run an update of tar1090 after that so the heatmaps were created before the update.
This is what I’ve seen since the update - The tropo has been decent today but not as good as yesterday.
It has been fun messing with this feature to say the least. I did a 72 hour run for my own amusement (filtered to 40k feet):
I find it amazing how closely the tracks color the heywhatsthat boundaries. Pretty cool stuff!
3 Likes
Hi, I am using Tar1090 for some time now. Since yesterday it looks like that I have an issue. After a while I have more than 3-4 times the amount of planes showing in tar1090 compared to dump1090. Dump1090 and graph1090 seem to show the correct amount of planes. I already removed and reinstalled tar1090 but this did not change? It looks like airplanes that leave the range of my receiver are not removed. At this moment I have 683 in tar1090 and 178 in dump1090-fa.
Any clue what can be wrong?
Toggle “P” - persistence mode.
Thanks. As simple as that. Stupid that I overlooked this.
I appreciate that you aren’t blaming the horrible UI design 
Anyhow once you’ve used the feature you recognize what is going on.
I think the UI serves it’s purpose, but I did recently disable the buttons in config.js on both my stations. Much cleaner look and it also removes that occasional accidental persistent mouse hover pop-up at the top. I noticed the keyboard shortcuts still work, so I still have my “P” when I need it.
Hello @wiedehopf.
I’m not sure if this relates to most recent commits on Github, but the RSSI column is missing on ADS-B Exchange when viewed from a Safari Browser (version 13.1.2 - one behind latest macOS version) .
I’ve brought my local tar1090 up to the current commit, and it does still show RSSI.
(Wondered why ADSB Exchange went blank earlier )
Update - Just checked Firefox (version 78.0.2) on my Mac and it is also missing RSSI, so not just a Safari thing. Also., there does not seem to be a way to grab the divider between the map and the data table to adjust the width.
The tar version used at ADSBExchange never shows the RSSI. At least for me the column never showed any values.
This is a remote install on ADSBx not your own, nothing you can change because you would need access to the config file as far as i understand.
You might need to discuss this on their support forum.
Well, i do get the message either way and i’m responsible for that flavor let’s say of tar1090 as well.
Data format change to reduce bandwidth used.
RSSI … forgot to handle 
It went blank because Safari is a crappy browser and doesn’t support lots of javascript functions.
Needed to work around that once i was made aware of the issue.
@foxhunter @wiedehopf sorry if I’ve breached protocol by raising an ADSBX issue on a Flightaware forum. Links to tar1090 on my local site and the ADSBX site both point to the same GitHub repository, so I assumed there was a common code base. If there is a more appropriate place to post feedback/questions, please let me know.
tar1090 is the main way I view my site and I just wanted to make a minor contribution by providing feedback on the latest commit. I don’t feed ADSBX, but often have my site and ADSBX tar1090 instances on split screen at the same scale and map background - it gives me an idea of what areas I can see that aren’t visible to other sites in my area. It also means I pick up minor differences in what is displayed.
@foxhunter, at least for me ADSBX has always shown RSSI. Here is a screen shot from four days ago (before the latest commits) - I was going to ask @wiedehopf about a minor difference, but decided not to waste his time. See if you can spot the issue
@wiedehopf agree Apple has a bad attitude re java in general - as a Mac user, it is just the path of least resistance (particularly handing off the sites you are viewing between different machines) to use it as my primary browser. Thanks for the ongoing development of tar 1090.
So if you regularly use it, why not contribute if you already have a receiver, the feed scripts are just as easy as installing tar1090. Data usage is much reduced compared to the scripts that were used a year ago, not quite as little data usage as feeding FA but it’s not more than double i think.
How the data is transferred is very different, that’s even more the case now.
I’ve rolled out something that wasn’t quite finished yet but it should be mostly finished now at least.
Just to be pedantic, i was talking about javascript not java, it’s very different.
So you’ll make me guess? I’m a curious person you know
no need to say sorry. All good.
Sure, but i assume you’re not responsible on how they implemented it, or?
Interesting, i haven’t recognized this since they moved from VRS to TAR
Well i implemented it. And i fixed the missing RSSI (and a couple other things i had overlooked)
It just looks the same, there is lots of code in tar1090 for supporting a global page.
Using the normal mode gets much too slow after maybe 500 aircraft or so.
After doing tar1090 for the home receiver last year i started working on a version that could display lots more aircraft.
1 Like
Just a thought on the global version, I really don’t see the need for RSSI since the ‘receiver’ is not really identified. I like it in on my ‘local’ tar1090 since I know the location of the antenna.