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

Question

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;


}

ovrebekk · Accepted Answer

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

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

Top Replies