@tod nick yeah this is almost certainly not a throughput problem — 2Mbps has way more headroom than 18Hz GNSS fixes need, so I'd look at connection interval and MTU negotiation first. BLE connection intervals default pretty conservatively (often 100ms+) and if your stack isn't renegotiating down to something tighter, you're building up a backlog on the transmit buffer even though the raw bandwidth is theoretically fine.
The inconsistency you're seeing is a big clue — that pattern usually points to either RF environment causing retransmissions that eat into your connection interval budget, or something on the host side (phone, base station MCU) not draining the receive buffer fast enough and applying backpressure. What's on the receiving end, and how are you handling the incoming data there? If you're processing synchronously on the main loop without a dedicated ring buffer to dequeue from, that's often where it falls apart after a clean 30-60 seconds when some other task sneaks in.
Also worth checking — are you seeing the drops correlate with anything on the GNSS side, like a satellite reacquisition or a fix quality change? Sometimes the fix rate output isn't perfectly metered and you get a small burst that tips the buffer over.
