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;