Cutting power to nrf51 after receiving spi bytes and advertising them using BLE

[aalsubhi]

Hi all,

I'm working on a limited power budget system. MSP430 is the master that is supplying power to nrf51882 (slave). Every 2s MSP430 derives a pin high to drive the nrf51's VCC high and send multiple bytes. nrf51 after receiving the bytes through spi , tries to advertise them.  Then MSP430 waits 200 ms(after sending the multiple bytes)  before cutting the nrf51 power off. I choose 200 ms because I set the advertisement interval on nrf51 to 100 ms. The issue I'm facing is cutting the power off on nrf51 , preventing the advertise packet from being discovered / received by a phone. But when I leave the power on (making MSP430 holding the pin high to source power to nrf51 all the time), I received the advertisement packet on my phone. I tried to increase the waiting time before cutting the power on nrf51 up to 1s but without any luck. 

I'm using soft device 110 and SDK v10. 

Is there any way to cut the power safely on nrf51 while insuring the advertisement packet at least advertised once ? 

or what is the best way to minimize the power consumption of using nrf51 as peripheral to broadcast a data that received from a master?

[Karl Ylvisaker]

Hello,

Every 2s MSP430 derives a pin high to drive the nrf51's VCC high and send multiple bytes. nrf51 after receiving the bytes through spi , tries to advertise them.  Then MSP430 waits 200 ms(after sending the multiple bytes)  before cutting the nrf51 power off.

Is there any way to cut the power safely on nrf51 while insuring the advertisement packet at least advertised once ? 

I would propose that you instead implement the nRF51 to go into SYSTEM_ON sleep mode whenever it finishes the advertisement. This way, you would know for certain that the advertisement has completed successfully, while avoiding spending time every 2 s to setup and configure the device.
You could make use of the Radio Notification to know that a radio event has completed. If you are only doing advertising, this will be the only type of event occurring.

As long as you uninitialize your peripherals and release the clocks when you are done with them, the average power consumption while in SYSTEM_ON sleep is quite low. This, combined with the time the device will have to spend every 2s in order to wake up and get ready leads me to believe that the SYSTEM_ON sleep option would give you a lower average current consumption and easier time implementing and controlling it.
This will also reduce the time it takes to wake-up and configure the device to make it ready to receive the SPI transfer, and setup and configure the SoftDevice.

Alternatively, for the lowest possible baseline current draw between transfers you could have the nRF51 go into SYSTEM_OFF sleep, and then waking it every so often through the pin interrupt - the important point here is that it should go to sleep on its own, whenever it is finished sending an advertisement, for example.

If you want to cut the power to the NRF51 completely between transfers, you could have it toggle a pin to communicate that it has completed an advertising, and then cut the power.

Please keep in mind that it is not guaranteed that an advertising packet will be received successfully by a central. The packet may be lost, corrupted or simply 'not read' (if the central is not scanning at the particular time of the advertising).
Advertisements have no acknowledgement, so the sender will never know if the advertisement successfully arrived at the central. However, a BLE connection is lossless, so any packets that are not acknowledged will be resent in the next connection event. If no packets are acknowledged, the link is terminated.

If it is important that you do not potentially loose the data in the advertising packets I would suggest that you instead enter into a connection with a very long connection interval. If the device is in SYSTEM_ON sleep it will be ready to wake up whenever an event is generated (such as a reception on the SPI peripheral (if enabled), or an upcoming radio event).

Best regards,
Karl

[aalsubhi]

Thank for you informative and fast response. I did some experiments to see if turning on nrf51 to send an advertisement then turn it off would work. It works fine by setting the advertisement interval to 100ms and make the MSP430 (master) wait more than 100ms (about 300ms-500ms) before cutting the power on nrf51 (slave).

The problem I faced if I enable spis on nrf51 and try to send some data, uninitiate spis to save power,  advertise the received data and then cut the power off, that nrf51 VCC is hinging at 1.5V after cutting the power although the spin and advertisement process are working fine, but this behavior (nrf51 is stuck at 1.4V) is causing a half amp current consumption which is very high for my system. 

On the other hand, If I don't use spis on nrf51 and just let the BLE advertise fixed data, every 2s when master (MSP430) powering on nrf51, wait 300ms-500ms  then cut power on nrf51, the nrf51 vcc goes low near Zero volt when the power is cut off and there is no high power consumption.

Here is my code : 

int main(void)
{   
    // Enable the constant latency sub power mode to minimize the time it takes
    // for the SPIS peripheral to become active after the CSN line is asserted
    // (when the CPU is in sleep mode).
    NRF_POWER->TASKS_CONSTLAT = 1;

    memset(m_tx_buf, 0, BUF_SIZE); // initializing  the TX buffer

    APP_ERROR_CHECK(spi_peripheral_init()); // Initialize SPI to receive sensor data from MSP430

    memset(m_tx_buf, 0, BUF_SIZE); // initializing  the TX buffer

    memset(m_rx_buf, 0, BUF_SIZE); // reset the RX buffer
    receiving_completed = false;

//    //Set buffers.
    APP_ERROR_CHECK(nrf_drv_spis_buffers_set(&m_spis, m_tx_buf, sizeof(m_tx_buf), m_rx_buf, sizeof(m_rx_buf)));
//
    while(!receiving_completed) // Wait for data from the Central (MSP430)
    {
        __WFE();   //stay in low power mode
    }
    nrf_drv_spis_uninit(&m_spis); // uninit spis to save power

    // Initialize BLE
    ble_stack_init();
    advertising_init();

    // Start execution.
    advertising_start();
    
    // Main loop.
    while(1)
    {
        
        power_manage();
    }
    
    
}

Do you have any idea why using spis preventing nrf51 vcc to shutdown completely (stuck at 1.4V) when the power is off leading to a half Amp consumption?

[aalsubhi]

Here is the current consumption of nrf51 when spis and BLE broadcast are used:

Here is the current consumption when I don't use spis and only use BLE advertisement:

You can see when SPIS is used nrf51 consumes around half mA even when the it is power off by the master (MSP430).

[aalsubhi]

I solved this problem. I used SPI mode 0 (CPOL = 0, CPHA = 0) on nrf51 and (CPOL=0 CPHA=1) on msp430. Also, I have to wait at least 3ms after turning the nrf51's power on before sending any data through spi.

[Karl Ylvisaker]

Hello again,

Thank you for your patience with this. The summer holidays have begun here in Norway, and DevZone is therefore operating with reduced staff for the time being. Sorry for any inconvenience this might cause.

aalsubhi said:

Thank for you informative and fast response.

No problem at all, I am happy to help!

aalsubhi said:

It works fine by setting the advertisement interval to 100ms and make the MSP430 (master) wait more than 100ms (about 300ms-500ms) before cutting the power on nrf51 (slave).

Do I understand this correctly that you went for a merge of the two approaches - having the nRF51 enter sleep mode on its own following completed advertising, and then cutting its power afterwards? If so, could you elaborate why you still opt to cut its power? I am interpreting 'cutting its power' literally, i.e that you toggle a transistor on its power supply lines, or similar. Do I have this correctly?
I would think that you could achieve lower power consumption by doing either of the things, like suggested in my previous comment.
Did you try the two approaches separately, to compare their power consumption?

aalsubhi said:

I solved this problem. I used SPI mode 0 (CPOL = 0, CPHA = 0) on nrf51 and (CPOL=0 CPHA=1) on msp430. Also, I have to wait at least 3ms after turning the nrf51's power on before sending any data through spi.

I am glad to hear that you were able to resolve this new issue! These 3 ms of wakeup cycles is what I was referring to as potentially negatable through keeping the device in SYSTEM ON sleep between advertisements.

Best regards,
Karl