Install Requirements/Manual Install

[tcassels]

Hello,

I'm curious if there's a list of requirements/directory structure for Tar1090 to operate fully? This is because I'm working on FreeBSD so the install script won't work. The initial testing is being done on Linux (my desktop) before I translate to the server. End goal is to have a server running readsb and Tar1090 with a secondary instance of readsb connected to the rtl-sdr to collect the traffic and sending it to the server.

There is no port of readsb or tar1090 as of yet available so everything is going to be manual.

Thus far I I've been able to put together the aircraft.csv.gz, readsb has been compiled and recording aircraft to json. Tar1090 is displaying the aircraft and I've worked through the errors reported thru various http errors. It is reading in the globe_* files, chunks, and the various files under data.

I am having issues with tracks, sometimes they're solid but most of the time they're dashed. I presume this is due to missed positions. The antenna is inside so not really that surprising at this point in time.

The other issue I'm having is history, I'm pretty confident I'm doing something wrong in this regard. Tracks will remain on screen until I refresh then they're gone. I don't see anything named history in the network monitor trying to be loaded, but I do see a trace_full*.json being called with the hex value of the aircraft, file is returned successfully but no track is displayed. Right after refresh when I select an aircraft, I don't see any failed http calls. I have a theory this might deal with the --tar1090-use-api argument. I haven't configured this yet because Tar1090 doesn't live behind a real webserver yet.

So I guess really this question is along the lines of, what files does Tar1090 need to function, were are they stored, and how are they populated?

readsb is configured with --write-json, --db-file, --write-globe-history, --write-json-globe-index, and --write-state. I'm omitting the less interesting arguments such as device-type.

[wiedehopf]

Cache issue for trace files?

Suppose you can't just use the nginx config that is available?

[wiedehopf]

As soon as you run globe-index ... a lot of the logic changes as it is for aggregators really.

The default setup doesn't use trace files but rather tar1090.sh will build up history in /run/tar1090 Chunks are not loaded unless you use /?pTracks once you use globe-index.

traces don't have all positions to save data (there is quite a bit of heuristic to record positions more frequently for track / speed / altitude changes). you can just specify json-interval 0.1 if you wish the traces to record all positions you receive.

Oh traces from trace_ files are only loaded when a plane is selected. The T button would create undue load for global maps, thus it doesn't load all the traces.

[tcassels]

The trace interval did the trick, thanks.

I went ahead and setup nginx and put the config in place. I presume "INSTANCE" is a placeholder to be swapped out for the tar1090 html directory?

I have tar1090.sh running with a first argument of tar1090/html/chunks and a second argument of tar1090/html/data. I presume this is as intended? I got here by comparing the output files of the script to the files returning http 404.

Not seeing any complains in the browser console or network monitor. After a period of time, I can select an aircraft and see it's track. Once I refresh, the track is gone and no errors are reported.

With those test results, I went ahead and added the --tar1090-use-api piece and it's communicating as well. I've also commented out most of the arguments I was providing readsb, it's down to --write-json-every, --json-trace-interval, --db-file, --lat/lon, --tar1090-use-api, and finally --net-api-port pointing to a unix socket.

Still no errors in the console or network monitor but upon page refresh and picking an aircraft, there's no historical track. It will display the track from the refresh point forward.

[wiedehopf]

json-interval has no effect at all if you're not using globe-index json-interval really shouldn't change if a trace is dotted, there is internal logic to prevent this.

Yes INSTANCE is a placeholder. tar1090.sh usually runs like this

/bin/bash /usr/local/share/tar1090/tar1090.sh /run/tar1090 /run/readsb

with /run/tar1090 being mapped to /tar1090/chunks and /run/readsb being mapped to /tar1090/data

[wiedehopf]

If you don't use globe-index, using the API is somewhat pointless. (as the total number of aircraft is sufficiently small so it doesn't hurt always getting all plane data)

[tcassels]

Ok, let me make sure I'm tracking.

For readsb, I want:

• --write-json pointing at the tar1090 data dir
• --write-globe-history pointing at the tar1090 data dir
• --write-json-globe-index
• --tar1090-use-api
• --net-api-port pointing at a unix sock

[wiedehopf]

I don't know if you want the globe-index or not. It very much changes up quite a bit of the behaviour of readsb + tar1090 as in home user vs aggregator. As in it has a bunch of stuff so if the whole globe is filled with aircraft, the webinterface doesn't slow to a crawl.

It depends on what you want.

And no --write-json should just point at /run/readsb typically. And the nginx config then exposes it at /data.

globe history on the other hand is /var/globe_history in the nginx config.

[wiedehopf]

Also, is there even a eventfd() and epoll_wait() implementation in FreeBSD? I suppose there is as you've probably compiled readsb.

You could just look at debian/readsb.service and debian/default The default install very much doesn't have persistence as i mentioned.

You could look at this as well i suppose: https://github.com/sdr-enthusiasts/docker-tar1090/

[tcassels]

Let me take a step back.

The current testing goal is to setup readsb with a rtlsdr and feed the data to tar1090 in such a way that it will display the traffic but also, after site refresh and clicking on an aircraft, displays the historical track. An architectural limitation I've imposed is removing the install script from the picture, primarily because I don't want a blind install, but I also want to choose the filesystem layout to better conform to my needs.

The only piece that currently does not function is the historical track displaying after refresh.

FreeBSD does not have epoll and I no longer run Linux servers so if that functionality is required, then readsb won't compile.

[wiedehopf]

If you want something custom you'll have to get a bit more familiar with the software. The tar1090 install script also performs cachebusting on the js when installing.

If your traces don't load with globe index the most likely issue that the nginx confix isn't applying the correct flags and stuff

location /tar1090/globe_history/ {
  alias /var/globe_history/;
  location ~ traces/ {
    gzip off;
    add_header Cache-Control "public, max-age=1209600";
    add_header Content-Encoding "gzip";
  }
}

location /tar1090/data/ {
  alias /run/readsb/;

  location /tar1090/data/traces/ {
    location ~ trace_recent {
      gzip off;
    add_header Cache-Control "public, no-cache";
      add_header Content-Encoding "gzip";
    }
    location ~ trace_full {
      gzip off;
    add_header Cache-Control "public, no-cache";
      add_header Content-Encoding "gzip";
    }
  }
 }

the traces are gzip compressed as emitted by readsb so the webserver needs to set the correct content encoding.

traces for the last 24h are in /run/readsb/traces .. while older traces are on disk in /var/globe_history

Good luck, i'm pretty much out as you won't be able to run readsb on freebsd anyhow without epoll / eventfd.