[BLE Central] Failed to exchange gatt MTU: err 0x0e

[Martdur]

Hello Nordic Team, 

I'm developing a BLE multilink central device, I've managed to connect and subscibe to differents devices but I have some troubles connecting and subscribing to one particular BLE sensor.

I'm working with two cycling power pedals from the same brand (One right one left), I managed to subscribe to the power characteristics of the left sensor, but I get error while exchanging the MTU with the right pedals(err 0x0e).

I'm using nordic connect sdk v2.2.0 with zephyr on custom board.

My config: 

Here is the log from the nrf53840 : 

Here the wireshark traces for both right and left pedals:

4341.FailedExaktRightt.pcapng

0131.SucceedExaktLeft.pcapng

I made some tests with my phone on the right pedals and everything was ok, here is the trace: 

3364.SucceedExaktRighPhonet.pcapng

I've tried other config like:

CONFIG_BT_AUTO_PHY_UPDATE=y

CONFIG_BT_GATT_AUTO_UPDATE_MTU=y

CONFIG_BT_AUTO_DATA_LEN_UPDATE=y

But this doesn't seems to help at all, making the connexion to both pedals fail.

Thanks in advance.

Martin

[Martdur]

For the moment I'm not setting the security, this may be the issue here.

I wanted to set the security only when needed but canno't find the BT_ATT_ERR_AUTHENTICATION  when subscribing as suggested in this post.

But as I described I can connect to the sensor with the phone without issues and without pairing.

[tesc]

Hi,

Regarding your configuration, I see:

CONFIG_BT_MAX_CONN=62

With the SoftDevice Controller the valid range is 0 to 20. Does this mean you are not using the SoftDevice Bluetooth LE Controller?

From the wireshark traces, I see that when failing for the right pedal the master (your device) attempts to start a database discovery (sending a read by group request) but there is no response back. It seems to be the slave (pedal) simply ignoring the connection events. It's hard to tell if it is resetting, or what is going on there. For the working case the database discovery is delayed until after a few other data exchanges including connection update indication. Maybe this difference makes the pedal behave differently, but I find it a bit strange the right pedal should behave differently from the left one.

Do you consistently see the connection time out for the right pedal, but not for the left pedal, irrespective of which pedal gets connected first?

This might be a hardware issue with the custom board. I assume you do not want to share any hardware files in a public ticket. Please create a new (private) ticket for sharing hardware files (schematics, layout files), so a colleague of mine can do a hardware review for you. Alternatively, let me know so I can make this thread private before you post it here instead.

Regards,
Terje

[Martdur]

Hi Terje,

Thanks for the quick response, I'd like if you can put this thread private.

tesc said:

With the SoftDevice Controller the valid range is 0 to 20. Does this mean you are not using the SoftDevice Bluetooth LE Controller?

So I tried to change it to softDevice but didn't managed to do so, there is some dependency that I cannot satisfied.

I didn't mentioned that earlier but I'm using ANT+ on the netcore.

  

tesc said:

Do you consistently see the connection time out for the right pedal, but not for the left pedal, irrespective of which pedal gets connected first?

Yes, I can connect the left on it's own but not the right, I haven't tried connected both.

 

tesc said:

This might be a hardware issue with the custom board.

I test my code on nrf53840 dk and everything went fine on both pedals .

So I suspect an hardware issue.

 

Hope we can discuss further on the Hardware design.

Have a great evening.

Regards

Martin

[Martdur]

What I can add is that we're using Laird BL5340 Multic-Core module.

[Kenneth]

Looking at the on-air log I can't find any good reason for this:

In one case the slave (right pedal I assume) does not seem to ack or respond to any of the data sent from the master. I do not see a good reason for this, other than one of the peers must be slightly out of spec, considering this works on one pedal, and the sniffer is able to pick up the data, I suspect it's the slave (right pedal I assume) that is problematic.

I do not see any good way to debug this, other than (if possible) use the radio test example to setup a constant carrier and measure the carrier on a spectrum analyzer that it's on the configured channel (e.g. channel 2 = 2.402GHz +- 96kHz). This will at least confirm that your master is within specification.

Kenneth