Issue regarding Nrf52840 long range mode

[BK]

Hi, I'm using Nrf52840 as the MCU for the developed product.

For my product, there is a central and a peripheral which two are communicate with each other via bluetooth. Currently, I set the adv_params.primary_phy = BLE_GAP_PHY_1MBPS for the peripheral, and .scan_phys = BLE_GAP_PHY_1MBPS for the central. They work perfectly. 

Now I wanna use the long range mode, so I change the BLE_GAP_PHY_1MBPS to BLE_GAP_PHY_CODED for both central and peripheral. However, after the modification, I found that they don't work and even I cannot find the peripheral anymore by using Nordic Connect App. Anybody knows why? 

Thank you so much!

[Stian Røed Hafskjold]

Hi, only 1 Mbps is supported on the primary advertising channel (per Bluetooth 5 core specification, Vol 6, part B, section 2.3), except for ADV_EXT_IND (used for extended advertising). So if you want to use CODED PHY you have to set up extended advertising, and the secondary advertising packets can be CODED PHY.

This blog is explains this a bit better: https://www.novelbits.io/bluetooth-5-advertisements/

The "Running speed and cadence application" example uses extended advertising, so you can look at this to see how to set it up.

Peripheral: https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.3.0/ble_sdk_app_rsc.html?cp=5_1_4_2_2_22

Central: https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.3.0/ble_sdk_app_rscs_c.html?cp=5_1_4_2_0_3

[BK]

Hi Stian, thank you so much for you rapid response, that's really helpful! 

So just to get to know that better, if I set up extended advertising, setting the secondary advertising to be CODED. Does that mean it will always use the secondary channel(CODED) instead of primary channel(1Mbps)? 

[Stian Røed Hafskjold]

The peripheral will still advertise on the primary channels (@ 1Mbps), but the packets (ADV_EXT_IND) will only contain information about the secondary channel which will have the actual data.

The central will still be scanning on the 1 Mbps primary channels, and when it receives the ADV_EXT_IND it switches to CODED (or whatever you specify) and receives the data on the secondary channel. This means that the central will still catch packets from other peripherals with normal advertising.

[BK]

Got it. 

I did the modification as below, (my SDK is 15.2)

For the peripheral: 

(1) Setting adv_extended_enabled = true

(2) in ble_advertising_start(), change the secondary_phy to CODED. 

Then, for the central:

Setting the .scan_phys to BLE_GAP_PHY_AUTO

However, I found that, after setting adv_extended_enabled to true in the peripheral, they cannot connect with each other anymore. 

Do you have any idea why is that? Probably there are some other places need to be modified also? 

Maybe it's because of the following one?

(it will change the adv type from SCANNABLE to NONSCANNABLE)

[Stian Røed Hafskjold]

If you start by debugging the code you can see if the ble_advertising_init function (or scan init) returns with an error code. If the error code is "invalid params" it's some of the parameters that are not according to spec. For instance both scannable and connectable is not supported with the extended advertising. So if you want to connect to the peripheral you will need connectable, non-scannable, undirected advertising. This is described in Volume 6, Part B, Section 4.4.2, Table 4.1 in the spec.

[awneil]

Stian Røed Hafskjold said:

If the error code is "invalid params" it's some of the parameters that are not according to spec

Sadly, this no help in determining which paramter(s) was invalid, nor how it/they were invalid.

https://devzone.nordicsemi.com/f/nordic-q-a/48490/graceful-recovery-from-bluetooth-errors/192270#192270

[Stian Røed Hafskjold]

I agree, but it's nice to know if the issue is because of wrong parameters either on the peripheral side or central side. Or, if the functions are returning "success", we need to look somewhere else.

[BK]

I just checked that there is no error(return zero) after executing ble_advertising_init() for the peripheral. Meanwhile, th central can receive advertising packets normally(because it can be receive the BLE_GAP_EVT_ADV_REPORT event), but somehow in those advertising packets received from various nearby devices, it seems that the specific paired peripheral(which the central want to connect to) cannot be found(by that, I mean, in my application, I will parse the received the adv packets to get the peripheral MAC address, and it cannot find that specific one anymore)

BTW, can I use nRF52840 DK and nRF sniffer application to sniffer the BLE 5.0 communication?