pc-ble-driver-py, mtu size, data length extensions and connectivity firmware

[john23094]

Hi,

I'm trying to develop an application that uses an nrf52840-dk board and the pc-ble-driver-py. The dk is supposed to be a central device.

Using the python driver library, I've got it to connect to another custom board (supposed to be a peripheral), that also uses an nrf52840 MCU. When it connects however, the custom board is supposed to negotiate a higher MTU size, packet data length extensions, and connection interval. It always does this when I connect to nRF connect on my smartphone, or anything else. But I can't seem to get it to do this with the dk and ble-driver-py. It connects, but never seems to negotiate anything. Should I make the dk (the central) try and negotiate?

The dk is flashed with connectivity firmware version: 4.1.4. SoftDevice API version: 5.

Is this a limitation of the driver and connectivity firwmare version? I can't find anything in the driver code relating to it. 

I'm also quite confused with the state of the pc-ble-driver and connectivity firmware. Can you confirm if the following is correct?:

• pc-ble-driver-py supports up to SD api v5 only, and s132 SD only
• Is there any way I can use SD s140 and v6 API? that's what my custom peripheral MCU is programmed with

[Hung Bui]

Hi Savvn, 

As far as I know the pc-ble-driver should support longer MTU size. Could you have a look at the workaround mentioned in this ticket and check if it work for you ? 
pc-ble-driver-py is a pretty old tool and will not have further update. But it should work with S140 with v6 API. Could you point me to where you got the information about: 

pc-ble-driver-py supports up to SD api v5 only, and s132 SD only

I would suggest to capture a sniffer trace so we know what exactly over the air. 

[john23094]

When I connect to my peripheral device, no MTU negotiation happens, only PHY update request. This is when I call the connect() function inside ble_adapter.py.

I'll take a look at that ticket now, it must have missed me when I was searching for similar posts on this topic.

I do realize it's an older tool, but we want to work in Python as its quicker for us currently to get this up and running with python. 

If you look inside pc-ble-driver-py/pc_ble_driver_py/hex/ only folders sd_api_v2 and sd_api_v5 are listed. 

Inside pc_ble_driver_py/lib you will find only nrf_ble_driver_sd_api_v2.py and nrf_ble_driver_sd_api_v5.py. Inside the code only references to 'v2' and 'v5' can be found.

On top of that, I've tried to flash my dk with connectivity fw that contains SD S140 and v6.1.1 API from here:

https://github.com/NordicSemiconductor/pc-ble-driver/tree/release/4.1.4/hex/sd_api_v6

And it wouldn't work, pc-ble-driver-py would report timeout

 

[Hung Bui]

Hi again Savvn,

Did you request MTU from the peripheral side ? If not, you may need to implement the request on the central's side. 

You are right that pc-ble-driver-py doesn't support API v6. You can have a look here.

But it's supported on pc-ble-driver C++ library. So you may consider use the pc-ble-driver instead. 

[john23094]

Hi Hung,

Yes the peripherals firmware is configured to negotiate higher MTU, correct conn. interval etc.

It always does this when connected to, say my smartphone running nRF connect app, or my machine's internal bluetooth adapter etc.

I tried the jlink workaround #2 with disabling mass storage, but no avail.

I'm going to look into wireshark now and sniff to see what is going on upon connection.

[Hung Bui]

Did you follow the workaround mentioned in the case I pointed to ? 
Of setting self.adapter.default_mtu = 247 manually ? 

Please capture a sniffer trace. If you have added in the code that the slave should request ATT MTU update, it should do that when connected, regardless which central it connects to. 

[john23094]

Ok I think I've gotten to the bottom of this.

I followed the OP's code in that other post.

This is what the adapter open code looks like:

self.adapter.driver.open()
self.adapter.default_mtu = 547

gatt_cfg = BLEConfigConnGatt()
gatt_cfg.att_mtu = 547
gatt_cfg.tag = CFG_TAG
self.adapter.driver.ble_cfg_set(BLEConfig.conn_gatt, gatt_cfg)

cfg = BLEConfigGapRoleCount(central_role_count=1, periph_role_count=0, central_sec_count=0)
cfg.conn_cfg_tag = CFG_TAG
self.adapter.driver.ble_cfg_set(BLEConfig.role_count, cfg)

cfg = BLEConfigConnGap(event_length=251)
cfg.conn_cfg_tag = CFG_TAG
self.adapter.driver.ble_cfg_set(BLEConfig.conn_gap, cfg)

self.adapter.driver.ble_enable()

After scanning, and discovering, I simply did something like this to connect:

self.adapter.connect(device_adv_data.peer_addr,conn_params=None, tag=CFG_TAG)

Now with this, it communicates the event data length and PHY (the max - 251. But NOT MTU size or conn. interval. This can be seen from wireshark:

I would have thought, like when connecting to anything else, the peripheral (server) should initiate these negotiations? I was wrong actually, it's the master that starts the MTU size negotiation. I saw this when comparing that trace, to another trace where I connect my peripheral to an iPhone X. So from OP's example in other post I added this code after the adapter connect.

logging.info('Requesting MTU exchange')
self.att_mtu = self.adapter.att_mtu_exchange(new_conn_handle, 517)

And now it negotiates the right size. So actually my knowledge of the connection process was not quite correct. But at least now I know how it's meant to go.

[john23094]

Actually, - to add, I have a new question.

Service discovery is quite slow if i initiate the connection with a longer connection interval.

Is it possible for a peripheral/server/slave device to know when service discovery is complete? I'd like the peripheral/server/slave to initiate negotiation for a higher conn. interval after the central/master/client has completed discovering the GATT table. This would be cool if possible, as I think that logic would be better on the peripheral's side in our device.

[Hung Bui]

Hi Savvn, 

We need to look into how in the slave side you request MTU exchange. There is a chance that if the central already request a bigger ATT MTU the slave will skip the request. But normally we should see the request from the slave. There isn't a way that the central can block the request from the slave from sending. 

Regarding your question about when the peripheral can detect when service discovery finished, I don't think it's possible , at least with our softdevice. 
What you can do is either change the connection interval from the central side. It's the case with many phones as the centrals. Short interval when doing service discovery and switch to long interval after that. 

Another option is to do a BLE activity, for example enable CCCD or write to a characteristic after service discovery is finished. Then the slave would have a call back and can check the connection interval and can request a longer one. 

[john23094]

The MTU size on the slave side is simply from example code, called when initing bluetooth.

/**@brief Function for initializing the GATT library. */
void gatt_init(uint16_t p_conn_handle)
{
ret_code_t err_code;

_gap_params_init();

_p_m_conn_handle = p_conn_handle;

err_code = nrf_ble_gatt_init(&m_gatt, _gatt_evt_handler);
APP_ERROR_CHECK(err_code);

err_code = nrf_ble_gatt_att_mtu_periph_set(&m_gatt, NRF_SDH_BLE_GATT_MAX_MTU_SIZE);
APP_ERROR_CHECK(err_code);

err_code = nrf_ble_gatt_data_length_set(&m_gatt, BLE_CONN_HANDLE_INVALID, NRF_SDH_BLE_GAP_DATA_LENGTH);
APP_ERROR_CHECK(err_code);
}

But like I said, with the code I posted above, after connecting, the master app using pc-ble-driver-py requests this max MTU size, and the slave now agrees (responds).

I used the sniffer and looked at the MTU negotiation procedure when connecting to nrf-connect on android, and it looked the same, master requested MTU extension first. I believe this is the correct behaviour no?

On the other point - yeah I realised that now after reading some other posts. It's fine I ended up using a timer on the slave after connection to ask for a new conn. interval.