wiedehopf

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.

That's only MLAT though and won't feed the ADS-B data.

Aircraft is in the air right now: https://globe.adsbexchange.com/?icao=a17b16&lat=54.936&lon=-...

Back to back turnback: https://globe.adsbexchange.com/?icao=a17b16&lat=42.330&lon=-... https://globe.adsbexchange.com/?icao=a17b16&lat=42.330&lon=-...

There are checklists for configuring everything as required.

Yeah i know it is what you want.

I'm just asking if it's really a reality as i previously got the impression airline training wasn't quite at that level. As in mostly you get an engine out because that needs training every time. And if the unexpected scenario is an engine out most of the time ... it's not really unexpected.

I wonder how often stuff like static port blockages and even maybe the flight director being wrong during takeoff are trained in an unexpected fashion. I'd expect quite rarely if at all. That's ok i suppose as it's rare failures, but the descriptions here kinda suggested a level of random scenarios being thrown at pilots ... which isn't quite realistic i think due to limited simulator time alone.

Is it really unexpected failures or do they discuss scenario / do you expect one of a few typical scenarios?

Really throwing failures at pilots without them knowing what's going on seems to mean too many fail or rather there is not enough time to train pre-discussed scenarios and do scenarios that aren't announced.

I'm not sure it's really what you'd want.

With batteries it's a bit more complicated as LiIon degrades faster at higher charge levels / voltages. So you're trading longevity for extra capacity in that case.

That's not Aireon data but rather ADS-C which is just Iridium data link as far as i know.

Exact tracks of both aircraft with timestamps: press K to enable labels https://globe.adsbexchange.com/?icao=a4eabe,a2cee7&lat=39.63...

ModeC MLAT ... is theoretically possible but you can't tell the aircraft identity and implementation is complicated and not planned.

We're not censoring anything.

They changed their transponders to either military stuff or ModeC which can't be easily identified.

TIS-B are traffic information broadcast by ATC so we're not getting signals directly from the aircraft.

No we don't need to fix the ports, we recommend installing a standalone decoder. Data going through fr24feed is likely not to work for MLAT. Anyhow that port 30003 is unreliable as fr24feed at least used to crash with multiple connections to it.

In a similar spirit: FR24 should fix their installs and ports.

A few pointers to get a receiver going if you're interested and don't want to use the Flightaware image: https://github.com/wiedehopf/adsb-wiki/wiki/adsb-receiver-sh... https://github.com/wiedehopf/adsb-wiki/wiki/Raspbian-Lite:-A...