I’ve been experiencing frequent disconnects with iOS SW Maps RTK BLE connections using a UM98x module, where NMEA-0813 (all SW Maps’ recommended sentences) and NTRIP RTCM payloads flowing concurrently causes BLE disconnect.
If I shut off NTRIP in one direction, or if I just reduce NMEA payload datarate (e.g., turn on only GGA and GST sentences) in the other direction, then no BLE disconnects. It seems that bigger payloads of things link GSV sentences simultaneous with NTRIP RTCM going the other direction breaks it within a few minutes.
I did several isolation experiments:
- Tried two other +5V VCC sources, to reduce likelihood of conducted noise / ripple
- Tried SW Maps running on Android tablet instead of iOS - can’t blame iOS BLE stack.
- Tried reducing from 115200 down to lower TTL bitrates. MTBF increased a little maybe.
- Eliminated UM980 from the equation by creating a test bench using PC w/ USB-TTL adapter running terminal app on one side, and Serial Bluetooth Terminal Android app (supports NUS) on the other. Half-duplex with continuous 115200 payload in either direction works indefinitely. It’s only when I start throwing doing full-duplex flows at it that causes disconnects. Observed symptoms are that the received flow (from BLE to TTL-TX) stops, and then 15-20sec later the red connection LED starts flashing (BLE not connected).
It seems to me that NMEA sentences as per SW Maps recommendations with typical NTRIP RTCM going the other direction is a reasonably moderate workload – its acting if there’s some kind of buffer management/overflow crash happening in the ESP32/Nordic code only during bi-direction flows.
Can somebody reproduce this, for example by connecting BlueSmiRF V2 to the UM-980 breakout? If not, then maybe my BlueSMiRF has some weird sample defect (I haven’t bought & tried another yet)…