Android与NRF52832间间歇性BLE吞吐量问题排查求助

Hey there, let's dig into this intermittent BLE throughput issue you're facing—this setup with Nordic chips and Android is super common, so I’ve got some actionable leads to help you narrow it down:

Let’s break this down into firmware, Android app, and environmental angles:

1. Firmware Side (nRF52832 + S132 v12.2) #

• Tweak Connection Parameters: The default S132 v12.2 connection settings might not handle 3 concurrent devices well. Check your ble_gap_conn_params_t configuration:
  • If your connection interval is too large (over 100ms) or slave latency is high, you’ll get fewer data transmission windows. Start with a 10-30ms interval, slave latency 0, and supervision timeout ~400ms to test stability.
  • S132 v12.2 has a known quirk with concurrent device contention—try setting a unique conn_interval_offset for each sensor to avoid syncing their transmission windows and causing air collisions.
• Optimize NUS TX Buffering: Nordic’s NUS relies on SoftDevice TX buffers; if your sensor sends large bursts, buffer overflow will cause drops/latency. Increase tx_buf_size in ble_nus_init_t to at least 256 bytes, and add flow control: have your Android app send an ACK after each packet, so the sensor only sends the next when it gets confirmation.
• Consider SoftDevice Updates: S132 v12.2 is pretty old, and Nordic fixed plenty of throughput-related bugs (like retransmission logic and connection scheduling) in later versions. If feasible, upgrade to S132 v14.2+ (just make sure to align your SDK version) to rule out legacy issues.

2. Android Side (Nexus 5X + Android 7.1.1) #

• Prioritize BLE Connections: Android 7.1.1 limits resources for concurrent BLE links. In your app, set high priority for each connection to ensure the system allocates enough bandwidth:

  BluetoothGatt gatt = device.connectGatt(context, false, gattCallback);
  gatt.requestConnectionPriority(BluetoothGatt.CONNECTION_PRIORITY_HIGH);
  

• Offload Data Processing: If your onCharacteristicChanged callback does heavy work (like IO or UI updates), it blocks the Gatt stack from handling incoming packets. Move processing to a background thread (use HandlerThread or coroutines) to keep the callback fast.
• Work Around Android 7.x Bugs: Android 7.x has known BLE stability quirks. Try disabling Bluetooth Scan Optimization in Developer Options, or resetting your phone’s Bluetooth module (Settings > Bluetooth > More > Reset Bluetooth) to rule out system-level glitches.

3. Environmental & Hardware Checks #

• Minimize 2.4GHz Interference: BLE shares the 2.4GHz band with WiFi, mice, and other Bluetooth devices. Test in a low-interference area, or switch your phone to 5GHz WiFi if supported, to reduce signal collisions. Also, check your sensor’s antenna—if it’s custom hardware, make sure it’s not blocked by metal or poorly matched (weak signals mean more retransmissions and lower throughput).
• Disable Battery Optimization: Nexus 5X’s Android 7.1.1 strict battery saving can throttle BLE when the screen is off. Add your app to the unoptimized battery list in Settings > Battery > Battery Optimization to keep connections stable in the background.

Quick Validation Steps #

1. Test with just one sensor first—if throughput is stable, the issue is definitely related to concurrent device scheduling.
2. Replace your app with Nordic’s nRF Connect to test throughput—if the problem disappears, it’s likely a bug in your custom app’s Gatt handling.
3. Add timestamp logging in both firmware (when packets are sent) and Android (when packets are received) to spot patterns in latency or drops.

Hope these tips help you pin down the root cause!

内容的提问来源于stack exchange，提问作者kabla002