Remote feeder on low bandwidth/metered internet

Hello! I’m looking for advice on the best practices for setting up a remote feeder on a low bandwidth/metered internet connection. Ideally I’d feed a single data stream (filtered to only send relevant messages) to a server on my home internet connection, where I would then be able to feed it up to multiple services (FlightAware, FR24, etc.) and view it on a local web server.

It’s not super clear to me how to best separate receiving, decoding, and feeding for optimal results. Should I just run dump1090-mutability on the remote receiver and run modesmixer2 and the various feeder services on my home server? And what should I do for MLAT? And TIS-B?


Timing requirements would eliminate MLAT in a setup like this due to the extra delays introduced.
Also keep in mind that activating MLAT locally “pushes” more data, almost double.

Similar topic Any way to reduce data usage? - #5 by rugomol

You can connect the input port 30004 of dump1090 on home box from reading the receiver box output port 30005.

Here is the connection diagram of piaware. You should probably disable piaware program or faup1090 on the receiver box OR only install dump1090. The home box should run full piaware software.

Receiver box running dump1090 --(limited bandwidth network)—> home box running piaware --(your main internet connection)–> FlightAware

The receiver box run dump1090
Either netcat or mode s mixer the receiver box port 30005 to home box port 30004.
The home box running piaware can then run other upload feeds.
MLAT, TIS-B, ADSB should work on the home box and it normally does.

Running MLAT is tricky. If the overall timing delays are low enough it should work but I recommend that you don’t bother if you are running limited bandwidth.

1 Like

Awesome. That diagram is tremendously helpful. I’ve done exactly as you suggested. Really, the bandwidth to feed FlightAware wasn’t the big problem–it was running VRS or SkyView so I could look at my own data that was eating up all my bandwidth. I’m still a bit worried that with ~800,000 positions per day the beast data feed may be a bit much, but so far it seems to be working ok so I’ll keep my fingers crossed.

MLAT doesn’t seem to be suffering so far, but I’ll keep an eye on it. Ping times are about 100ms from my remote feeder to the home network, then 55ms from the home network to, so hopefully that isn’t too much. About 25% of my aircraft are MLAT so I want to make it work if I can,.


Hmm, to me that was too much, “My ADS-B” web page was informing me that there are timing issues at several ms delay.

If you think about it, radiowaves travel with 186,282 miles per second (299,792 kilometers per second).
For a 10 ms (0.010 sec) delay, the difference in the “perceived” distance by MLAT will be 1863 miles. That’s not good enough. I guess there is a “mechanism” to compensate for a fixed delay, but in my case those delays were hardly constant (pings can vary significantly).

sonic the problem arises mostly when the usb connection or dongle is not stable as far as i understand. (i believe the FAQ says something similar)

ads-b aircraft messages with known positions are used to establish a timebase in relation to the internal clock of the 1090mhz receiver.
so say you have received an ads-b message from aircraft A with a position and shortly after (same second or so) you receive a message from aircraft B without a position. now you can find out when you received the message from B relative to the time aircraft A sent it’s message as you know it’s and your position.
this difference in reference to the message from A is sent to the MLAT server which hopefully got this difference from 4 stations. that means it does not need to know when A sent the message, it can still calculate the position of B based on the fact all received delays are relative to fixed point in time.

hope that makes some sense.

P.S.: still want to know if my suggestions regarding pi-hole and lighttpd worked

Thanks for the suggestions, no, it did not work. Right now I am using the ModeSMixer2 and that works (port 8787), so I gave up to Skyview.

Yes. This is very close how the server side MLAT timing is done. Relative timing is calculated and as long as the relative timing is consistent the clock is usable. Clocks that bounce around or skip are bad and will be kicked off MLAT.

The most important parts is the radio to the USB connection on the computer. The timing has to be very accurate on this part. The internet packets can then take a second or two to reach FlightAware and still be usable for MLAT.

There are also other ways to lower the bandwidth. I am guessing you are running 2GB/month on your remote site which is probably not extremely bad and still within a lot of the free bandwidth limits of cellphone networks.