@Ashley Anderson yeah this sounds pretty familiar — the UART side is almost always where the headaches are when the BLE link itself is clean.
To answer your burstiness question directly: yes, expect bursts. Even at a steady 2Mbps BLE link, the data coming out of the module's UART isn't metered out as a smooth byte stream — it'll tend to come in chunks aligned to BLE connection events and packet boundaries. So you can get short high-rate bursts between quiet gaps, which is exactly the kind of thing that trips up a DMA circular buffer if your consumer thread isn't draining it fast enough between those events.
The thing I'd look at first isn't actually the buffer size — 4KB should be plenty if the consumer side keeps up. The more likely culprit is your DMA interrupt or idle-line detection config. If you're only processing the buffer on DMA half/complete callbacks, you might be missing a burst that arrives and partially overwrites unread data before you get to it. The UART idle line interrupt is your friend here — on STM32L4 you can trigger a callback whenever the line goes quiet after a burst, which gives you a much tighter processing window. Combining that with your circular DMA is the standard pattern and it usually kills this class of bug.
On the framing side, I'd point you to the GitHub repo —
https://github.com/RFOXiA/MultiNav-Pro-Long-Range-BLE-Module-Firmware-STM32WB07 — the firmware source should give you a clearer picture of how the module structures its output than the datasheet prose does. If the framing has any explicit packet delimiters or length fields you can parse on the fly, you'll be able to detect and discard partial packets gracefully rather than seeing them as corruption.
