Peer manager and chip/SD/SDK select

[hunterliuyi]

Hello, guys,

We have developed our first generation product with 51822(16KB RAM, SDK10, S110V8.0) as peripheral , and we are always facing the problem that the connection time between smart phone and our device is too long(over 2s) ,after some test ,we found the most time-costing procedure is service discovery,it tooks about 80% of the connection time(we can not afford to change the advertising interval too small since our product is battery powered, we have changed the connection interval to 20ms, and we just have two services, one is Device Information with 5 chars, another is our custom service with 4 chars), so we try to eliminate service discovery during connection according to the fact that bond will let smartphone cache service info so service discovery is only needed when bonding,which is acceptable.

We plan to add bond function to our existing project, and after some searching and reading here, we found that :(if I were wrong ,please correct me, THX)

1,Peer manager is production ready in SDK11

2,SD110 is no longer supported above SDK10

3,We have to change our chip to QFAC with 32KB RAM, since our application RAM is already about 7KB,and S130 will need at least 10KB RAM.

4,Peer manager is quite complex, integration and test may take some time.

from the cost of developing (migration of SDK and SD ,integration of Peer manager ) and chip upgrade, we are quite doubt that the choice of add bonding is right.

So ,we would like to ask:

1,Is there any other way to shorten the connection time?

2,Or if not ,we indeed have to implement Peer manager, can we shrink the peer manager function to only support JUST WORKS BONDING(this will save RAM usage and code size ,so no need to upgrade the chip)?

3,And if we can ,how to do that?

Thanks a lot.

updated：

my BLE GAP event handle code is like that :(it has been assigned by softdevice_ble_evt_handler_set())

void BSP_Ble_Periph_Event(ble_evt_t *pEvent) 

{
    
static U32 timer;   // 超时断开计时器
    ble_gatts_evt_write_t *pWrite;
    T_EventArgs e;
    
    // 检查事件对象
    if (pEvent->evt.gap_evt.conn_handle != s_tThisData.ConnHandle) {
        if ((pEvent->header.evt_id) != BLE_GAP_EVT_CONNECTED) {
            return;
        }
    }
    
    // 处理事件
    switch (pEvent->header.evt_id) {
        // 连接
        case BLE_GAP_EVT_CONNECTED: {
            Debug(__INFO__, "Connected [%02X:%02X:%02X:%02X:%02X:%02X]", 
                  pEvent->evt.gap_evt.params.connected.peer_addr.addr[5], 
                  pEvent->evt.gap_evt.params.connected.peer_addr.addr[4], 
                  pEvent->evt.gap_evt.params.connected.peer_addr.addr[3], 
                  pEvent->evt.gap_evt.params.connected.peer_addr.addr[2], 
                  pEvent->evt.gap_evt.params.connected.peer_addr.addr[1], 
                  pEvent->evt.gap_evt.params.connected.peer_addr.addr[0]);
            s_tThisData.ConnHandle = pEvent->evt.gap_evt.conn_handle;
            s_tThisData.ConnParams  = pEvent->evt.gap_evt.params.connected.conn_params;
            e.Type = EventType_Connect;
            e.Status = EventStatus_Seccess;
            BSP_Ble_Periph_EventCallBack(&e);
            Delay.Start(&timer);
        } break;
        
        // 断开
        case BLE_GAP_EVT_DISCONNECTED: {
            Debug(__INFO__, "Disconnected");
            s_tThisData.ConnHandle = BLE_CONN_HANDLE_INVALID;
            s_tThisData.AdvData.Data[27] = False;   // 关闭连接请求
            _AdvertisingStart();
            e.Type = EventType_Disconnect;
            e.Status = EventStatus_Seccess;
            BSP_Ble_Periph_EventCallBack(&e);
        } break;
        
        // 接收数据
        case BLE_GATTS_EVT_WRITE: {
            pWrite = &pEvent->evt.gatts_evt.params.write;
            T_Char *pChar = _GetChar(pWrite->handle, 0);
            if (pChar != Null) {
                if (pWrite->handle == pChar->Handles.value_handle) {
                    s_tThisData.ReadBuff.Len = pWrite->len;
                    memcpy(s_tThisData.ReadBuff.Data, pWrite->data, s_tThisData.ReadBuff.Len);
                    e.Type = EventType_Recived;
                    e.Value = pChar->UUID.uuid;
                    e.Data.Len = s_tThisData.ReadBuff.Len;
                    e.Data.p = s_tThisData.ReadBuff.Data;
                    BSP_Ble_Periph_EventCallBack(&e);
                }
                else if (pWrite->handle == pChar->Handles.cccd_handle) {
                    if (pWrite->len == 2) {
                        if (pWrite->data[0] == BLE_GATT_HVX_NOTIFICATION) {
                            pChar->NotificationFlag = True;
                        }
                        else {
                            pChar->NotificationFlag = False;
                        }
                    }
                }
            }
            Delay.Start(&timer);
        } break;
        
        // 广播超时
        case BLE_GAP_EVT_TIMEOUT: {
            _AdvertisingStart();
        } break;
        
        // 连接参数更新
        case BLE_GAP_EVT_CONN_PARAM_UPDATE: {
			Debug(__INFO__,"PARAM_UPDATE");
            s_tThisData.ConnParams = pEvent->evt.gap_evt.params.conn_param_update.conn_params;
            sd_ble_gap_conn_param_update(s_tThisData.ConnHandle, &s_tThisData.ConnParams);
			Debug(__INFO__,"min int %d max int %d slave lat %d timout %d",
				s_tThisData.ConnParams.min_conn_interval, 
    			s_tThisData.ConnParams.max_conn_interval,
    			s_tThisData.ConnParams.slave_latency,
    			s_tThisData.ConnParams.conn_sup_timeout);
            if (Delay.Check(&timer, 180000)) {
				Debug(__INFO__,"Connection Timeout!");
                BSP_Ble_Periph_Disconnect();
            }
        } break;
        
        case BLE_GAP_EVT_SEC_PARAMS_REQUEST: {
            Debug(__INFO__, "BLE_GAP_EVT_SEC_PARAMS_REQUEST");
            sd_ble_gap_sec_params_reply(s_tThisData.ConnHandle, BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP, NULL, NULL);
        } break;
        
        case BLE_GATTS_EVT_SYS_ATTR_MISSING: {
            Debug(__INFO__, "BLE_GATTS_EVT_SYS_ATTR_MISSING");
            sd_ble_gatts_sys_attr_set(s_tThisData.ConnHandle, NULL, 0, 0);
        } break;
    }
}

and the print from 51822 when SAMSUNG S7 connecting is like that: 

It seems the smart phone try to update the connection parameter with conn int 6**(unit is supposed to be 1.25ms)** lots of times ,and finally it have to change the connection interval to 39.

the print from 51822 when OPPO R11 connecting is like that:

The param update finished very quickly,and they finally agree to 9.

I am not sure it is the 51822 rejecting the 6 conn int, but I want to know why two different phone act differently,and why 6 connection interval can not be achieved.

Thanks a lot, if you need more information, please let me know.

UPDATED AGAIN:

after remove sd_ble_gap_conn_param_update() at BLE_GAP_EVT_CONN_PARAM_UPDATE, the param update procedure for two different android phones both reduce to twice,and the parameter finally get to 36 or 39, although the phone try to set 6.

the print for SAMSUNG S7 is like that:

and the print for OPPO R11 is like that:

And I check the time of DFU, two phones are almost the same(R11 was much faster than S7 before).

Can I say it all depends on phone to decide the connection parameter? why can not be set to 6?

If I want to initialize the param update from peripheral, Where should I call sd_ble_gap_conn_param_update()? how to achieve the 7.5ms connection interval(it seems both phones supports 7.5ms)?

[Petter Myhre]

You can try to reduce the connection interval. See this on how to check what it actually is.

I'm assuming that you are not bonding at all now? You can try to use Device Manager, which Peer Manager replaced. This is available in SDK 10. Check out the ble_app_hrs example. Try setting IS_SRVC_CHANGED_CHARACT_PRESENT to 0 to not include the service changed characteristic.

I'm not sure how easy it is to shrink the Peer Manager. If you just need simple bonding to one device you may be better of implementing your own bonding library, but this would take some work as well.

[hunterliuyi]

Hello, Peter, We have checked that our original connection interval is 20ms for the min and 40ms for the max ,which are the shortest value complying to the requirement of IOS .we found a problem that some android phone will try to update the value to 7.5ms lower than the min value directly, after several times of this trying, they change the value to 48.75ms,exceeding the max range of 40. Some other android phones will change the value to 11.25ms which is also below the min value,and we found that the DFU time of later android phone is much faster then the former phones .So I have questions, why the connection interval can not be set to 7.5ms and 11.25 is valid? and it seems that the original min and max is useless, because the final value can be either larger or smaller than the range,why?

[Petter Myhre]

It is the central device that dictates the connection interval. The initial connection interval is decided by the central and is included in the connection request. Then the central can do a connection parameter update to change the connection interval. The peripheral can only request the central to do an connection parameter update.

[Petter Myhre]

So if you get a connection interval outside the min or max, you have three options, send a connection parameter update request, accept the values even though they are outside what you prefer, or disconnect.

[hunterliuyi]

Yes, I know it all depends on the central, but why 7.5ms can not be set as the final value? Do I have to do something special to enable 7.5ms connection interval?