@Omar Johnson yeah your propagation math is right, at 50km you're looking at ~167µs one way which is basically irrelevant — the real latency budget is almost entirely BLE stack behavior, not physics.
The dominant factor is going to be connection interval. BLE is fundamentally a polling protocol, so if you're running a connection interval of say 100ms, your worst-case latency before the stack even gets a chance to transmit is that full interval. The STM32WB07 on the MultiNav Pro+ gives you control over connection interval parameters, so if you're latency-sensitive you'll want to tune that down — though there's a tradeoff with power consumption and potentially link stability at the edge of range, though at 50km drone-to-drone with clean line of sight you've probably got margin to play with.
Retransmit logic is the other wildcard. If the link quality is clean, you won't see much impact, but if you're getting any packet loss the automatic retransmit adds a full connection interval per retry in the worst case. Worth logging your RSSI and monitoring whether you're seeing any retransmits once the setup is running — the GitHub repo has the firmware source so you can get a sense of how the retry logic is implemented and instrument it if you need to.
Practically speaking for telemetry at that range with good antenna placement, I'd expect observed round-trip in the low-to-mid hundreds of milliseconds if you're running default connection intervals, and you can push it lower if you tune aggressively. What's your actual latency tolerance for the application — are we talking real-time control loop or just "I want fresh data every N seconds"?
