@Dawn Ryan good question, and honestly one that doesn't get talked about enough in the context of long-range BLE deployments.
The propagation delay itself is essentially a non-issue at 40km — you're looking at maybe 130 microseconds round trip, which is completely irrelevant. The real latency comes from the BLE connection interval, and that's the number you actually want to get your hands on. At default settings you're typically in the 7.5ms-to-hundreds-of-ms range depending on how the connection parameters are negotiated, and if your application isn't explicitly requesting a short interval, it tends to drift toward whatever the peripheral wants to use to save power.
For a telemetry use case at that range, the thing that'll kill you isn't propagation, it's retransmit events. BLE uses acknowledgment at the link layer, so any packet that doesn't get acked within the connection event gets queued for the next interval. At longer range with lower SNR margins, you see more of this even when the link is "working fine" — the module is running at extended sensitivity settings to get that range, and there's a real tradeoff between sensitivity and error rate that shows up as occasional latency spikes rather than clean drops.
Honestly the best thing I'd suggest is to instrument it yourself with timestamps at both ends over a test session and look at the distribution, not just the average — the tail latency is usually the thing that matters for a deployment decision. If you're on the STM32WB07 firmware side, the GitHub repo has the source so you can dig into the connection event configuration directly and tune the interval for your specific latency vs. power budget. Would help to know whether you're doing one-way telemetry pushes or actual request-response round trips, since those behave pretty differently.
