Central - use public address

RE: Central - use public address

Tue, 10 Jan 2017 10:12:41 GMT

Ok. Thank you very much.

RE: Central - use public address

Jørgen Holmefjord — Tue, 10 Jan 2017 09:57:59 GMT

You set it in the ble_gap_addr_t structure, along with the address. As mentioned above, you do not have to do this, as the softdevice handles this for you. If you want to set the address from FICR yourself, you can use the following code:

static ble_gap_addr_t m_central_addr;

m_central_addr.addr_type     = BLE_GAP_ADDR_TYPE_RANDOM_STATIC;
m_central_addr.addr[0] = (uint8_t)NRF_FICR->DEVICEADDR[0];
m_central_addr.addr[1] = (uint8_t)(NRF_FICR->DEVICEADDR[0] >> 8);
m_central_addr.addr[2] = (uint8_t)(NRF_FICR->DEVICEADDR[0] >> 16);
m_central_addr.addr[3] = (uint8_t)(NRF_FICR->DEVICEADDR[0] >> 24);
m_central_addr.addr[4] = (uint8_t)NRF_FICR->DEVICEADDR[1];
m_central_addr.addr[5] = (uint8_t)((NRF_FICR->DEVICEADDR[1] >> 8) | 0xC0); // 2MSB must be set 11

sd_ble_gap_addr_set(&m_central_addr);

RE: Central - use public address

Mon, 09 Jan 2017 14:45:00 GMT

Where do I use this setting BLE_GAP_ADDR_TYPE_RANDOM_STATIC?

RE: Central - use public address

Jørgen Holmefjord — Mon, 09 Jan 2017 13:57:16 GMT

If you set the address type to BLE_GAP_ADDR_TYPE_RANDOM_STATIC, the address will be constant but not entirely unique, as it is randomly generated during production. However, with 2^46 combinations of addresses, the chance of getting two devices with the same address is practically zero. As long as you do not call sd_ble_gap_address_set() anywhere in your code, this is the default behaviour of the softdevice, so you should not have to change anything. The FICR registers cannot be changed, meaning your device will keep the same address for its whole lifetime.

RE: Central - use public address

Mon, 09 Jan 2017 13:45:53 GMT

*constant and unique

RE: Central - use public address

Mon, 09 Jan 2017 13:43:48 GMT

I don't mind the address type being random, as long as the address is constant (i.e. each time the central connects to the peripheral it will identify itself using the same address)

RE: Central - use public address

Jørgen Holmefjord — Mon, 09 Jan 2017 13:36:20 GMT

You can use the device address from FICR to fill the address struct, but this is what the softdevice does by default (if no address is found in FICR, a random address is generated). If you want a public address, you have to register this with the IEEE Registration Authority.

RE: Central - use public address

Mon, 09 Jan 2017 13:30:02 GMT

Does this mean that I have to generate my own address for the central? I wanted to use the one that is already preprogrammed inside the chip by Nordic.

RE: Central - use public address

Jørgen Holmefjord — Mon, 09 Jan 2017 13:11:50 GMT

You can set the address using sd_ble_gap_address_set() for S130 v2.0.1 softdevice (sd_ble_gap_addr_set() for latest S132 v3.x.x softdevice for nRF52832). It takes the same address struct as described above, ble_gap_addr_t, as agrument, and you should set the addr_cycle_mode argument to BLE_GAP_ADDR_CYCLE_MODE_NONE.

RE: Central - use public address

Mon, 09 Jan 2017 13:00:41 GMT

Hi Jorden. Thank you for your reply. It seems that I didn't explain myself correctly. I need the central to identify itself using the public address. Right now when it connects to my peripheral, the peripheral shows peer (central) address type as random. Thanks

RE: Central - use public address

Jørgen Holmefjord — Mon, 09 Jan 2017 12:31:41 GMT

Hi,

There should be no difference in the way you connect to a peripheral with a public or a random address.

The softdevice function sd_ble_gap_connect() takes a pointer to the address struct, ble_gap_addr_t, as agrument. This should be filled with the address and the address type. By setting the type to BLE_GAP_ADDR_TYPE_PUBLIC, you can connect to a device that has a public address.

If your central is scanning for advertising packets from the device before connecting, you can pass the address struct included in the advertising report, peer_addr, directly to the connect function.

Best regards,

Jørgen