This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Odd BLE notification problem, Windows 8.1

So I have my nRF51822 updating the characteristic value and sending notifications once every time I receive a radio notification.

uint8_t readings[20] = { 0, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18 };

void bleRadioNotificationHandler(bool radioState)
{
        if(!isConnected || !radioState || !drSmartService.notificationsEnabled) return;
        bleServiceUpdate(drSmartService, readings);
        ++readings[0];
}

Initially I had bleServiceUpdate in a while loop untill it encountered BLE_ERROR_NO_TX_BUFFERS

It worked just fine.. with nRF Master Control Panel on Android, the notifications were received correctly and in order. The interval was set to 7.5ms.

Then I tried using my Windows 8.1 application, that however completely refused to receive the notifications properly. Not only the API was reporting that it received 24 bytes (my characteristic is actually 20 bytes) but what it received was garbage, and it didn't change at all:

14 6050403 e0d0c0b 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Then I tried changing the min and max connection intervals to 500ms, it didn't change anything. At that point I went ahead to verify the characteristic contents by requesting the data manually instead of subscribing to the notifications. All fine there. Now I put it in a loop to see how fast it was. And to my suprise, it was fast. Wayyy too fast. I set the connection interval to 500ms, remember? And I was able to request MANY packets extremly quickly. Rought measurement gave me a result of around 16ms per packet. Bumping the connection intervals up to 1s, same thing. 16ms. How is this possible?

This is my GAP init function

uint32_t bleGapInit()
{
    uint32_t errorCode;
    ble_gap_conn_params_t connectionParams = { NULL };
    ble_gap_conn_sec_mode_t securityMode;
    
    BLE_GAP_CONN_SEC_MODE_SET_OPEN(&securityMode);
    errorHandle(sd_ble_gap_device_name_set(&securityMode, (uint8_t*)DEVICE_NAME, strlen(DEVICE_NAME)));
    errorHandle(sd_ble_gap_appearance_set(BLE_APPEARANCE_GENERIC_RUNNING_WALKING_SENSOR));
    
    connectionParams.min_conn_interval = MIN_CONN_INTERVAL;
    connectionParams.max_conn_interval = MAX_CONN_INTERVAL;
    connectionParams.slave_latency     = SLAVE_LATENCY;
    connectionParams.conn_sup_timeout  = CONN_SUP_TIMEOUT;
    
    return sd_ble_gap_ppcp_set(&connectionParams);
}
  • Hi

    You should try to set the max and min connection interval to a slightly different value in order to give the central device (win 8.1) a little choice on which value to set for the link. Otherwise it might not change the connection interval at all. See this thread how the connection parameter negotiation works. Also see this thread on how to identify the actual connection interval on the link.

    I am not sure what is happening on win 8.1 side. Probably the best way to find out is to sniff the on air packages with e.g. the nRF sniffer. What happens when you try to transmit only a single packet? Try to change the parameters mentioned here to see what happens.

  • After reading the Windows BLE API headers that haven't been documented on MSDN I found out I was just using it wrong.

Related