@Jessica Bradford yeah this is a pretty interesting use case and honestly one I've been curious about too. The 2Mbps PHY gives you a lot of headroom on paper but you're right to think carefully about what actually makes it through once BLE's connection interval structure and the L2CAP/ATT overhead eat into it.
The short version is: for low-bitrate compressed voice (Opus at 8-16kbps, something like that) you should be fine even at a few KM, but continuous streaming behaves differently from bursty telemetry and there are a few things worth keeping in mind. BLE isn't really designed as a streaming transport — it's connection-event based, so your actual throughput depends heavily on your connection interval and how many packets you can squeeze into each event. At 2Mbps PHY with tight connection intervals you can realistically push somewhere in the 1-1.5Mbps effective range, which is way more than you need for voice, but if you're far out and the link quality drops, the stack will start retransmitting and your effective throughput and latency both get worse simultaneously, which is painful for audio.
The bigger thing to watch at range isn't raw bandwidth — it's latency jitter. Audio needs consistent delivery timing more than it needs raw speed, and BLE's retransmit behavior can introduce variable latency that a jitter buffer has to absorb. You'll want a decent buffer on the receive side and probably Opus with its built-in PLC (packet loss concealment) handling dropouts gracefully rather than just cutting out.
Has anyone actually tried continuous streaming on this hardware specifically — would love to hear from others in the thread too. But conceptually there's no reason it shouldn't work for voice at the ranges you're describing. What's your target codec and bitrate?
