51822 power consumption issue with PA added

RE: 51822 power consumption issue with PA added

AmbystomaLabs — Fri, 28 Sep 2018 12:39:53 GMT

I just wanted to make sure you saw my reply with the code for radio notification. The new devzone has this bug where it hides some replies.

RE: 51822 power consumption issue with PA added

wangyong — Fri, 28 Sep 2018 01:57:56 GMT

RFX2411N has SWANT pin which allows user to disable/enable a specific channel. So I suppose that ANTA channel is disable with existing hardware configuration. Anyway I will do some testing with adding an 50ohm resistor to GND. Many Thanks to your reply

RE: 51822 power consumption issue with PA added

wangyong — Fri, 28 Sep 2018 01:57:23 GMT

RE: 51822 power consumption issue with PA added

AmbystomaLabs — Thu, 27 Sep 2018 21:02:51 GMT

If you ever do a rev of this board you should terminate ANTA into 50 ohms since you are not using it.

RF switches can fry easily with open circuits due to the high voltages that can be present. Better to be safe and just terminate unused RF ports.

RE: 51822 power consumption issue with PA added

AmbystomaLabs — Thu, 27 Sep 2018 20:41:48 GMT

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.

RE: 51822 power consumption issue with PA added

AmbystomaLabs — Thu, 27 Sep 2018 20:00:19 GMT

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.

RE: 51822 power consumption issue with PA added

wangyong — Wed, 26 Sep 2018 09:10:36 GMT

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

RE: 51822 power consumption issue with PA added

wangyong — Wed, 26 Sep 2018 08:16:06 GMT

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.

RE: 51822 power consumption issue with PA added

AmbystomaLabs — Wed, 26 Sep 2018 06:51:15 GMT

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.