Share received signal timing with nearby paragliders to triangulate Mode-S receivers

Background

The majority of aircraft currently do not transmit their position information, and rely on ground stations to triangulate them. This is a problem for in-aircraft displays like paradar, because without ground stations feeding us information (or an RF direction finding setup) it's hard to figure out where a mode-S signal comes from.

Pilot Aware/Sky Demon solves this by showing "directionless targets", but I don't like this so much - it seems confusing for the user. Ground stations might let us do MLAT (alternatively, receiving Pilot Aware's data via their module presumably provides this via their ground stations).

Proposal

Paragliders/paramotors fly in groups with near-ideal separation for triangulation, largely unlike other aircraft. This provides an opportunity to accurately triangulate signals we receive that don't have position information in them - like the bulk of mode-S transponders. Paradar includes a GPS receiver which provides extremely accurate time, and the Raspberry Pi incorporates bluetooth and wifi transmitters. Can these be adapted in software to communicate between adjacent paradars to triangulate mode-s aircraft?

Projects like https://github.com/mutability/mlat-server suggest that this is feasible, and for an aircraft 1km away would require timing of received signals accurate within ~1us. A GPS PPS output is accurate to less than 100ns, though interrupt jitter adds error ~6us - suggesting 6-10km accuracy. This is probably on the lower edge of useful, but feasible for an experiment.

The range could be extended (so this works with fixed-wing aircraft, or cross-region) if I incorporate a LoRa transmitter or similar with 20km+ range. Alternatively, consider extending the P3i protocol allowing for compatibility with Pilot Aware devices.

This work follows on from #5, which includes building a custom SDR backend (a fork of dump1090 that's faster, supports frequency-hopping and collects timing information).
Once that exists, measure how accurately Linux can timestamp received packets through the SDR using the GPS and the system clock as an accurate timing source, and whether this work is feasible as a software update to the existing hardware platform.
If so, investigate whether it's feasible to broadcast packets via the WiFi interface and receive them on nearby devices. Test the range of this.
Finally, implement a backend element that listens for those packets from nearby devices, calculates the likely vector of the aircraft based on timing information and feeds that to the display logic.

Open questions

What's the range on the Pi's WiFi transmitter?
Does Linux support sufficiently accurate timing for this? (~1-2 us)
Could I do this with a software update to the existing SDR platform, or do I need a dedicated 1090Mhz tuner to increase accuracy?
Could something like linear regression and information sharing between many devices improve overall accuracy?

Other notes/references

https://www.rtl-sdr.com/thesis-on-locating-transmitters-with-tdoa-and-rtl-sdrs/ file:///home/blinken/Downloads/DPTX_2018_1_11320_0_522240_0_208913.pdf http://www.rocketmanrc.com/openpps-development.html

Consider extending the hardware platform to add a dedicated 1090Mhz RF frontend, with GPS PPS information muxed in. This would allow very accurate timetstamping of received signals (the PPS is already mixed with the received data) Alternatively, maybe a microcontroller doing the mode-S and a 1090Mhz tuner provides enough accuracy, which can be supported by the Pi or an ESP32.

blinken / paradar