This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Changing the default Channel Map with sd_ble_opt_set

Hi,

We're designing a product with the nRF52 (SoftDevice S132 v5.0.0 production) and an external WiFi module, and are attempting to do a "poor man's WiFi Co-Existence" by disabling all BLE channels that overlap with the known WiFi channel.

It appears that we are able to successfully set the Channel Map like so for WiFi Channel 1 (no errors are returned):

static uint8_t m_ch_mask[CHANNEL_MAP_BYTE_CNT] = {0x00, 0xfe, 0xff, 0xff, 0x1f};  //disable BLE channels overlapping with WiFi Channel 1
ble_gap_opt_ch_map_t channel_map = {0};

channel_map.conn_handle = conn_handle;  //we get conn_handle on a CONNECT event
memcpy(channel_map.ch_map, m_ch_mask, sizeof(m_ch_mask));

ret_code_t err_code = sd_ble_opt_set(BLE_GAP_OPT_CH_MAP, (ble_opt_t *)&channel_map);
if (err_code != NRF_SUCCESS) {
    LOG(LOG_LEVEL_ERROR, "failed to set channel map: %d\r\n", err_code);
    return -1;
}

However, when reading back the Channel Map using sd_ble_opt_get, we still see the default channel map: ff ff ff ff 1fwhen connecting from a laptop. When connecting using the nRF Connect app, we see something other than the default channel map; however, some of the bits set to 0 in the mask during sd_ble_opt_set are set to 1 when reading it back with sd_ble_opt_get.

I did read a couple of other related posts on the DevZone:
How to Change Channel Map for exchanging DaTa ?
How to correctly set channel map of next connection?

However, even waiting minutes after the connection is made, we still see bits set to 1 with sd_ble_opt_getthat were set to 0 in sd_ble_opt_set.

Is there anything we're missing? Is this functionality being used successfully by anyone with S132 v5.0.0?

Parents
  • Hi,

    Is this a central or peripheral device?

    As mentioned in the first devzone post you linked to:

    It's only the master that can set the channel map, so setting the option on a peripheral will not have any immediate effect. It will only affect future central links, which is why it is allowed to do to begin with.

    So to change the mask, you have to initiate this from the central side.

  • Hi Mike,

    No, this map is not communicated from the peripheral to the central. Only the central is allowed to request a change in the channel map.

    From the BLE Specification version 4.2 Vol 6, Part B, page 237:

    5.1.2 Channel Map Update Procedure

    The Link Layer parameter for channel map (channelMap) may be updated after entering the Connection State. The master can update the channel map by sending an LL_CHANNEL_MAP_REQ PDU. The slave shall not send this PDU.


    But it may be possible to implement some form of coexistence using the PA/LNA control support in the SoftDevice. These signals could be used to signal the WiFi chip when it needs to mute due to BLE activity (given that the WiFi chip support it).

Reply
  • Hi Mike,

    No, this map is not communicated from the peripheral to the central. Only the central is allowed to request a change in the channel map.

    From the BLE Specification version 4.2 Vol 6, Part B, page 237:

    5.1.2 Channel Map Update Procedure

    The Link Layer parameter for channel map (channelMap) may be updated after entering the Connection State. The master can update the channel map by sending an LL_CHANNEL_MAP_REQ PDU. The slave shall not send this PDU.


    But it may be possible to implement some form of coexistence using the PA/LNA control support in the SoftDevice. These signals could be used to signal the WiFi chip when it needs to mute due to BLE activity (given that the WiFi chip support it).

Children
No Data
Related