Best Practice for Custom GATT Service + Mesh GATT Proxy Coexistence on nRF52840

[Rajeev K R]

Use Case: We are developing a Bluetooth Mesh people-counter on the nRF52840 DK.

• Primary: Mesh network for publishing/receiving sensor data.

• Secondary: Custom BLE GATT interface for direct device access.

Architecture:

• Mesh: Config, Health, and Sensor (Server/Client) models.

• GATT: Custom service with Read (count), Write (config), and planned Notifications/MTU exchange (500 bytes).

• Config: BT_MESH_GATT_PROXY=y and BT_MESH_PB_GATT=y.

Questions:

1. Is it recommended to expose custom GATT characteristics alongside the Mesh Proxy on the same connection?

2. Does this scale? Can we add notifications and MTU negotiation without Mesh stack conflicts?

3. Option A vs. Option B:

   • A: Single Mesh Proxy advertiser + custom GATT service.

   • B: Extended advertising with separate identities (per ble_peripheral_lbs_coex). Which is better for a production device requiring both Mesh and Peripheral features?

4. Best Practices: Are there specific Kconfig requirements, registration orders, or callback handling tips for this coexistence?

Environment:

• Hardware: nRF52840 DK

• SDK: nRF Connect SDK v2.8.0 (Zephyr 3.7.99)

[Amanda Hsieh]

Hi, 

I am working on your case and will reply next week. 

Regards,
Amanda H.