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