Comment by rootusrootus
20 hours ago
You can get containerized feeders for services like fr24 (e.g. liggy1/fr24feed) but that may not meet your requirements since it's really intended to handle everything from the sdr to the API, not siphon off data you are collecting some other way and then feed it.
Yeah I definitely don't want to run an opaque container either. We're already collecting and storing the data... I am happy to throw the data over via a udp socket or http request, but I don't want random software that we don't control running...
If you're not comfortable running my readsb (fork of dump1090) which is the feed client used by live / lol / fi and some other sites, then you can probably just send them data using socat.
Most of them will have port 30004 open for their ingest domain, usually feed.domain.com. Thus you'd hook up socat to 127.0.0.1:30005 (i assume you run dump1090 or readsb locally as a decoder). And make socat send that to feed.adsb.lol:30004 and/or feed.airplanes.live:30004
If you're in a remote location, you don't need to worry about mlat-client as MLAT requires at least 4 receivers that receive common aircraft.
Is there a good documentation (or maybe code) reference to the protocols that get used here? Running readsb is fine enough by me, but I'm just interested in how these systems work. I see some mentions of a Beast format. And then there's the mlat-client too
Thanks! After doing some more digging I suspected something like this was the simplest solution! Thanks for confirming.
1 reply →
I had the same concerns awhile back and ending up running a slightly modified version of https://github.com/wiedehopf/mlat-client -- not quite as simple as an http push, but much simpler than a containerized feed client.
That's only MLAT though and won't feed the ADS-B data.