pairing problem by the device name based on the multi-link example

[Duncan Xu]

My code is on the multi-link example and it works well when I use another nrf52dk board as the "Nordic_Blinky" peripheral device, but it can't find my other BLE device.

Is it the right function to find and pair the device name from the advertising report? 

(ble_advdata_name_find(p_adv_report->data.p_data,
                                         p_adv_report->data.len,
                                         m_target_periph_name))

I already change the target device name fitting to my BLE device and I am using nrf52dk and SDK15.

Thank you in advance.

[Edvin]

Hello,

Are you sure that your other BLE device advertises with it's full name? I don't know if your other device is also from the Nordic SDK, but you should be aware that it is also possible to advertise without a name, or to advertise with a short name. These will not be picked up if you are filtering on advertising names.

 

So either try to add the advertising name to the advertisement of the other device (if you are able to change the source code on this device, or you can try to filter on something else, like the UUID. Check out the ble_app_uart_c example found in SDK\ble_central\ble_app_uart_c. The function on_adv_report() in main.c calls ble_advdata_uuid_find() to search for a specific UUID.

Exactly how this is done depends on what version of the SDK you are using.

 

Best regards,

Edvin

[Duncan Xu]

Hi Edvin,

I print out the advertising report and find the problem is exactly the same as you said, which has its UUID part but without the name. But when I use my phone to receive that device's advertising report, there is the data about UUID and name. I can't figure out why two reports from the same device are different. If it is about the scan filter police, where can I access it?

Thank you very much

Duncan 

[Edvin]

Hello Duncan,

It may be that the name is either in the scan response packet (But then you should be able to get it by scanning, but not in the first packet), or it might be that the name is found in the discovery process, after connection. Or, another possibility is that if you are developing this device yourself, the phone might remember it's name from when the name was in the advertising packet. 

You can try to filter on the UUID. If you look at the ble_app_uart_c example (SDK\examples\ble_central\ble_app_uart_c), which does this. See how it is done in the on_adv_report() function in main.c.

 

Alternatively, do you know how the phone finds the advertising name? Can you find the name in nRF Connect for Desktop?

Did you make this second device yourself (i.e. can you modify the source code)? Can you see if the advertising name is included in the scan response data (srdata)?

 

Best regards,

Edvin

[Duncan Xu]

Hi Edvin,

I can see the data of the name from the raw data report with the data format of 0x17 in my phone. I also tried to filter in UUID, but when I used another official example "ble_app_beacon", I found it the UUID was actually in the manufacture data so the function(ble_advdata_uuid_find) failed. Now, I try to use the peer address to do it. Is the peer address unique for each individual Bluetooth device?  

Thanks.

Duncan

[Edvin]

Hello,

Yes. The peer address is unique for each device. The device address of each device is found in the UICR registers. You can to flash a board and scan for it in nRF Connect for Destop, where you will see the peer address. compare it with the UICR peer address register using nrfjprog:

nrfjprog --memrd 0x100000A4 --n 8

 

Note that the first bit in a bluetooth address  is always 1, so the UICR register may differ from the address on that bit. On my board the most significant byte is 0x51, but the address starts with 0xD1.

 

Is there something in the advertising data that you can use? I guess if you know what the entire advertisement packet would be, or parts of it, you could just filter on that by comparing p_adv_report->data.p_data[i] with what you know it will be advertising.

 

Best regards,

Edvin