8mA current draw with timeslot API, BLE + Gazell host, softdevice 130

[Spok]

As the title suggest, I am running into an issue where my nrf51822 bluetooth keyboard is drawing around 8mA, which I think is way too much.

I am using gazell protocol to communicate between the 2 halves of the keyboard (it is split in 2), and one weird thing that I noticed is that when commenting out the sd_radio_request() from my init function, the current draw drops by about 4mA. I think the 4mA remaining is due to UART and debug mode, but I don't understand why gazell should draw this much. On the other half, running gazell as device, the current draw is less than 50uA.

uint32_t gazell_sd_radio_init(void)
{

    uint32_t err_code;
    err_code = sd_radio_session_open(m_radio_callback);
    if (err_code != NRF_SUCCESS)
        return err_code;
    m_configure_next_event();
    err_code = sd_radio_request(&m_timeslot_request);
    if (err_code != NRF_SUCCESS)
    {
        (void)sd_radio_session_close();
        return err_code;
    }
    return NRF_SUCCESS;


}

[Spok]

One more discovery : if I try to lower the length of the timeslot (from 10 000 us to 5 000 us),  my power consumption goes way down (to about 3.5 to 4.5 mA). But the reliability of the connection between the halves too. 

Here is my timeslot configuration

 m_slot_length = 5000;                                                        
 m_timeslot_request.request_type = NRF_RADIO_REQ_TYPE_EARLIEST;               
 m_timeslot_request.params.earliest.hfclk = NRF_RADIO_HFCLK_CFG_NO_GUARANTEE; 
 m_timeslot_request.params.earliest.priority = NRF_RADIO_PRIORITY_NORMAL;     
 m_timeslot_request.params.earliest.length_us = m_slot_length;                
 m_timeslot_request.params.earliest.timeout_us = 100000;  

[Spok]

Actually, now that I think of it, could it be that a gazell host will always draw this much current. Looking back at the specification, I see that gazell devices should be very power efficient, but I cannot find current consumption figures for the gazell host.

It is ok for me to put a bigger battery in it, but I would like to make sure that I am not missing something obvious first.

[ovrebekk]

Hi 

The Gazell protocol is optimized for the peripheral to dongle scenario where you have low power peripherals like keyboards and mice talking to a USB dongle with ample power available. As such it is correct that the host will always keep the receiver on, to make sure the device can reach it as quickly as possible. 

Have you considered using BLE rather than Gazell for the communication between the two halves?

If you run the S130 SoftDevice on one of the halves it can set up one link as a peripheral and one as a central at the same time, and you can run the S110 SoftDevice in the other half to connect to the central link of the first. 

You might have to give up a bit of flash memory, but you should get a more power optimized solution. 

Best regards
Torbjørn

[Spok]

Hi,

Thanks for your reply, this is very interesting indeed.

Would you have a link to a sample project for running S110 and connecting with BLE to a central link ?

Edit: I have started looking into it, and I am not sure why s110 is better suited as BLE peripheral than s130. 

I am marking your answer as "verified" since you answered my original question.

[ovrebekk]

Hi 

Sorry for the slow response. I forgot to include the verified cases in my active list. 

The S110 uses less flash, so you have more available to your application. Other than that there is no reason why you can't use the S130 for a peripheral only device. 

Most of the BLE peripheral examples in the SDK show you how you can use either the S110 or the S130 to make a connection to a central device. 

Best regards
Torbjørn