FlightAware Discussions

Tar1090 -- improved webinterface for dump1090-fa and readsb

Mine looks similar:

Yeah, he should probably find it. It’s just cosmetics anyway, the graphs are ok, the stats at FA are not affected, it’s just annoying :rofl:

Since he’s busy working with the airspy-decoder (more important than a single user problem) I’ll try for a while more.

Yepp, that was also my problem. Graphs are looking ok, but the live view in the map showed the double rate.

Maybe something with the data stream

I am currently testing forwarding of the whole stream from VRS to tar1090. Doing that shows an extreme value of > 9000 msg because it’s a combined stream.

Yeah, I did check that as well. Killed VRS and disabled it completely (including removing the config for the receivers in VRS). No difference…

then my limited skills end here…

And I appreciate the help :slight_smile:

It could of course be a bug somewhere in either readsb or tar1090 (not very likely). I might spend some time looking into the source code to see if I can spot something obvious. I’m running a 64-bit system, it shouldn’t affect it, but how knows…

1 Like

Would you put this on pastebin please?

jq < /run/readsb/stats.json '.last5min'

During my test on my root server with Ubuntu x64 and a single source, i also did not see that issue. So this should really not cause an issue

  "remote": {
    "modes": 216708,

That per 5 min is about 700 per second.

The graphs only show the accepted messages.
readsb is rejecting a big part of the messages for:

    "unknown_icao": 161575,

Which means it hasn’t seen a DF17/DF11 message from the same icao in the last minute or so.
That would suggest you’re somehow producing a lot of bogus messages.
Which brings us to the airspy settings :slight_smile:

1 Like

No, it shouldn’t. But I’ve seen peculiarities when running things on 64 bit platforms that was not written properly (and I know that this is not the case with code @wiedehopf produce).

As soon as I saw these numbers I changed -w from 5 to 6. It got better, but it’s still rising, but at a slower pace.
I’ll keep experimenting.

Just a curious question, why do the bad icaos get included in the message rate display? I didn’t see this when running dump1090-fa and tar1090.

Thanks for the help.

The default range for the HeyWhatsThat contour is 40,000 ft - alts=12192 [13343]
While that is adequate for trans-Atlantic flights, in US, the internal flights are up to 38,000 ft.
Can the “Up In The Air” range be changed?

You need to download the file again. meanwhile there’s a script in the tar directory called getupintheair.sh


This file contain the section

if [[ -n $2 ]]; then

modify the value after ALTS to what you want, save it and run it again.
It will download the range again. For running it you need the appropriate parameter from heywhatsthat.

1 Like

Pretty sure it’s the same and you just didn’t have the gain as high or something different.

I don’t understand that. I have a map number from them and that’s all.
You mean run again the .sh I guess?

That is what i mean with “code”:


Launch the script and add the 8-digit-code which you have on your screen.
I assume that’s what you say as “map number”


sudo ./getupintheair.sh <8-digit-code>
after you changed the value in the script to what you want. The value in the script is meter altitude

Ah, yep.
I see that input it’s written somewhere inside the “/usr/local/share/tar1090/html/upintheair.json”.
But yes, your approach seems to work. Thanks!

LE: Reboot tar1090 is needed? It didn’t take.

Yes, that’s a variable which you return while running the script (see above).
Technically you can also change the value and add your code directly. But that would go beyond your question.