https://devzone.nordicsemi.com/f/nordic-q-a/3321/nrf51822-stops-broadcastingHey folks, I am having a little trouble with my nrf51822 at the moment and needed some help. I am currently using a highly modified version of the ble_app_temp project with 2 accelerometer inputs, one as a wake up sense pin and one that is polled everyen-USTelligent Community 13Tue, 23 Sep 2014 20:01:01 GMThttps://devzone.nordicsemi.com/thread/12096?ContentTypeID=1Tue, 23 Sep 2014 20:01:01 GMT137ad170-7792-4731-bb38-c0d22fbe4515:60355265-7972-47c4-ad31-868e8b4ac9d4Chris Butler<p>I have kept working on the problem and about 2 weeks after I posted this we came across the compatibility docs for the chips. These pointed out that we were using the the latest sdk with a previous chip revision. Once we got the most recent chips everything seems to be working.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/12095?ContentTypeID=1Mon, 22 Sep 2014 13:55:34 GMT137ad170-7792-4731-bb38-c0d22fbe4515:c8a3b528-2c48-402d-9051-3540fdee3da9Asbj&#248;rn<p>The current consumption you describe should be a good indication to what&#39;s happening. The .2 mA period (if it&#39;s short) sounds like the start up current for the 16 MHz internal RCOSC and then into the main loop. If you run code from RAM the current consumption would be around 2.5 mA, if from flash it should be around 4 mA. Then the 0.7 mA sounds like you have the internal 16 MHz RCOSC running (750 uA).</p> <p>It sounds like one of your peripherals are interrupting your sleep and hence not going into the correct sleep mode again. That the advertising stops sounds like you are outside your normal routine and in a wait state for some SPI/UART/I2C event that you did not intend? Could it be that one or more of your GPIOs are floating during sleep and could cause the chip to wake at unfortunate moments?</p><div style="clear:both;"></div>