51822 power consumption issue with PA added

[wangyong]

Hi Everyone,

RFX2411N is used to extend signal coverage of NRF51822. Here are the configuration below:

1. Use radio notification to generate an interrupt 
2. Use this interrupt and a GPIO pin to control RXEN. 
3. Connect VDD_PA to TXEN and let this control the switching between PA and LNA mode.

And the problem is:

       sometimes radio signal  interrupt is missed which causes incorrect GPIO configuration. Thus power consumption is pretty high. 

We have quite a few products in field with customer complain about the power consumption issue.  

[AmbystomaLabs]

The interrupt will never be synchronous with the tx/rx activity due to the nature of the softdevice. You should use radio events and ppi/gpiote to drive the rx enable pin instead of an ISR. PPI can't be lost like an isr. Though I doubt your isr is getting lost, more likely a logic mistake in the code.

[wangyong]

Hi  AmbystomaLabs:

Atthached is the hardware connection

How should I use PPI/gpiote to drive rx enable pin instead of ISR?

BTW, We use S110 currently. 

[wangyong]

void SWI1_IRQHandler(void)
{
    m_radio_active = !m_radio_active;
    if (m_evt_handler != NULL)
    {
        m_evt_handler(m_radio_active);
    }
}

 

We use m_radio_active flag to control rx enable pin in existing software.  But now we have issue as described above in field

[AmbystomaLabs]

I looked into this, and I think I jumped the gun on suggesting you can solve it with PPI/GPIOTE. The events aren't structured properly to allow you to solve this that way.

On m_radio_active, I think the issue you are running into is there is no knowledge there of RX/TX ( I assume you are getting it from elsewhere).  Also, they appear to just toggle this boolean which isn't the most reliable approach.

The best approach would be use use PA/LNA Assist, but according the the SD spec, Nordic has not included it in nRF51 series softdevices.  It is only in nRF52 softdevices.

The absolute best approach would be to use radio notifications. With radio notifications you get an interrupt at a preset time before a radio event.  Within the interrupt you can determine if it is either:

1. Radio about to go into Tx mode.

2. Radio about to go into Rx mode.

3. Radio just having been disabled.  ie, just finished either Tx or Rx.

This with some simple logic will allow you to manage your external PA/LNA solution.  You should keep your logic very simple.  At best you can have 5500usec before the event and the SD will likely interrupt you and halt your process well before then.

Straight from the SD spec: "To ensure that the Radio Notification signals behave in a consistent way, the Radio Notification shall always be configured when the SoftDevice is in an idle state with no protocol stack or other SoftDevice activity in progress. Therefore, it is recommended to configure the Radio Notification signals directly after the SoftDevice has been enabled."

I'll put together some sample code for what it should look like and you can fine tune it and use it in your app.

[AmbystomaLabs]

Here is some code for you to work with.  It will completely replace your other logic.  I recommend you keep the notification distance to a minimum since this will reduce your battery consumption.

Here is the table for NRF_RADIO->STATE from the reference manual:

I am making the assumption that the radio knows which state it will be in when you get the notification.  You could hedge your bet on this by turning on the LNA for either RxRu, RxIdle, in addition to Rx.

Here is the code:

#include "ble_radio_notification.h"

#define RADIO_NOTIFICATION_IRQ_PRIORITY 2
#define RADIO_NOTIFICATION_DISTANCE NRF_RADIO_NOTIFICATION_DISTANCE_800US


void radio_notification_evt_handler(bool radio_evt)
{


	
    	if (radio_evt && (NRF_RADIO->STATE==0x3))
    	{
	NRF_GPIO->OUTSET = (1UL<<22);		
	} 
	else
	{
	NRF_GPIO->OUTCLR = (1UL<<22);
	}
			

}



	//Include this in main AFTER you have started the SD but BEFORE you start advertising.

	err_code=ble_radio_notification_init(RADIO_NOTIFICATION_IRQ_PRIORITY,RADIO_NOTIFICATION_DISTANCE,radio_notification_evt_handler);
    	APP_ERROR_CHECK(err_code);
    	
    	
    	
    	

You will notice I just clear the RX pin without logic.  It doesn't really matter if we clear it after a Tx event and it is safer to just make sure it is cleared whenever it shouldn't be on.