Raspberry bluetooth problem

[navarrocantero]

Hello, I have a problem with my nrf52832 customised board

It has loaded the ble_app_uart example of the  15.2_SDK and It have the correct pinout from my board, These are almost all my changes in the code.

I connect it with a raspberry pi3 (the last available model too) and a BLE dongle installed with a code based on node and using the noble library . (Otherwise I have tested python with another library called bluepy and It generate the same behavior) 

In raspberry pi3 I have a node server running, which communicates with another node server, both have the bluetooth code to connect with the customs boards.

When I have more than one raspberry or more than one custom boards turned on  , the customs boards becomes more unstable, and I get the feeling that it is because of the negotiation parameters about the connection.

I have followed the next ( docs.mbed.com/.../ ) to understand each parameter and can change it adequately but the same behavior has received. For these reason I let the parameters like the ble_app_uart from SDK_15.2

What can do I ? Thanks !

So the general schema will be :

1-Custom board emit SSID

2- Raspberry (with noble or bluepy or whatever)  connect to the SSID

3- and that's all

[Vidar Berg]

Hello,

It's interesting that you seem to get the same behavior with both Noble and Bluepy. Have you tried using the built-in BT device on the Raspberry Pi as well?

The sniffer trace is shows that the central terminates the link, so I think the you need to debug this on the Raspberry side. The central should generally not disconnect because of connection parameters requested by the peripheral.  

[awneil]

Vidar Berg said:

The central should generally not disconnect because of connection parameters requested by the peripheral

Indeed - they are just a request.

Certainly Android will make the connection - even when it does not grant the requested connection parameters.

[navarrocantero]

Hi thanks for reply !!

Yes, Previously I Work with the built-in BT adapter from raspberry pi, in my raspberry pi 3 model B. 

After that I updated it to the pi 3 model B+, and finally I buy a bt-dongle usb adaptator.

With all configurations I have the same behavior .

The core of my app is can read a char from the central and toogle a led. Is all that I want;

My code is based on ble_app_uart from the 15.2 SDK and my changes on these code are :

- correct pinout in the 10040.h board file

- in the nus_data_handler() method I have some changes, to toogle a led, and remote restart:

char thisAction;

static void nus_data_handler(ble_nus_evt_t *p_evt) {
    if (p_evt->type == BLE_NUS_EVT_RX_DATA) {
        uint32_t
        err_code;


        for (uint32_t i = 0; i < p_evt->params.rx_data.length; i++) {

            do {
                err_code = app_uart_put(p_evt->params.rx_data.p_data[i]);
                thisAction = p_evt->params.rx_data.p_data[0];
                if (thisAction == 0x61)  {
                    nrf_pwr_mgmt_feed();
                    bsp_board_leds_off();
                    bsp_board_led_on(BSP_BOARD_LED_2);
                    nrf_delay_ms(300);
                    bsp_board_led_on(BSP_BOARD_LED_0);
                    bsp_board_led_off(BSP_BOARD_LED_2);
                }
                if (thisAction == 0x62) {
//                    NRF_LOG_ERROR("%s", "OK_B");
                    nrf_pwr_mgmt_feed();
                    bsp_board_leds_off();
                    bsp_board_led_on(BSP_BOARD_LED_0);
                }
                if ((err_code != NRF_SUCCESS) && (err_code != NRF_ERROR_BUSY)) {
                    NRF_LOG_ERROR("Failed receiving NUS message. Error 0x%x. ", err_code);
                    APP_ERROR_CHECK(err_code);
                }

            } while (err_code == NRF_ERROR_BUSY);
        }
        if (p_evt->params.rx_data.p_data[p_evt->params.rx_data.length - 1] == '\r') {
            while (app_uart_put('\n') == NRF_ERROR_BUSY);
        }
    }

}

Can theses changes make it so unstable? 

[Vidar Berg]

Hi,

I don't think your code changes is causing the problem here. It could be a problem with Bluez considering it fails with both Noble and Bluepy.  Have you tried to disable long MTU+DLE? I think it can be worth a try. 

Disable long MTU and DLE in sdk_config.h:

diff --git a/examples/ble_peripheral/ble_app_uart/pca10040/s132/config/sdk_config.h b/examples/ble_peripheral/ble_app_uart/pca10040/s132/config/sdk_config.h
index 45e634d..4bec73b 100644
--- a/examples/ble_peripheral/ble_app_uart/pca10040/s132/config/sdk_config.h
+++ b/examples/ble_peripheral/ble_app_uart/pca10040/s132/config/sdk_config.h
@@ -11956,7 +11956,7 @@
 // <i> Requested BLE GAP data length to be negotiated.
 
 #ifndef NRF_SDH_BLE_GAP_DATA_LENGTH
-#define NRF_SDH_BLE_GAP_DATA_LENGTH 251
+#define NRF_SDH_BLE_GAP_DATA_LENGTH 27
 #endif
 
 // <o> NRF_SDH_BLE_PERIPHERAL_LINK_COUNT - Maximum number of peripheral links. 
@@ -11985,7 +11985,7 @@
 
 // <o> NRF_SDH_BLE_GATT_MAX_MTU_SIZE - Static maximum MTU size. 
 #ifndef NRF_SDH_BLE_GATT_MAX_MTU_SIZE
-#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247
+#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 23
 #endif
 
 // <o> NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE - Attribute Table size in bytes. The size must be a multiple of 4.