• Do you know for sure that bleUpdateServices is called? When you disconnect, advertising gets started regardless. NRF.sleep was only intended to be called when you don't have an active BLE connection so doesn't really do anything very clever.

    My guess is that the pulse in power usage is due to calibration of the internal RC oscillator. The nRF52 uses the RC oscillator most of the time, but occasionally it checks the temperature and compares to the high speed oscillator to make sure it's still keeping good time.

  • No, that was just a guess. What I see is that the connection breaks down. From the source code it is clear, that the BLE stack goes into sleep mode. Then later it wakes up again. The mentioned function looked like a candidate. But if you say that the NRF.sleep() is not supposed to be called with an active connection that's fine with me. I was just not expecting that and thus thought initially it might not work. Personally I think a hint in the documentation might be helpful there.

    The RC oscillator sounds like a possible reason. Since it is short and only occurs every 7 seconds or so that's no issue for me.

    The remaining issue is the behavior before calling "NRF.setAdvertising(...)" for the first time. There the power really goes up for 3.5 s and ramps down for 3.5 s. In think there is some serious current flowing during that time (if one accepts 80 uA as serious :-) - well, if the expected current is 20 uA, then 80 uA is serious). This goes away after calling NRF.setAdvertising(...) for the first time. Since I now have a workaround there is no big problem for me, but I think it is something to be looked into - if anyone else can reproduce it...


Avatar for Stevie @Stevie started