Avatar for Stevie

Stevie

Member since May 2015 • Last active Dec 2016
  • 4 conversations
  • 46 comments

Most recent activity

    • 13 comments
    • 5,858 views
  • in Puck.js, Pixl.js and MDBT42
    Avatar for Stevie

    Okay, the little arrow I overlooked so far. That's really useful. I can certainly add something there in the future.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Stevie

    Thanks for double checking! I will try the same with my scope. And I agree, let's not chase ghosts.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Stevie

    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...

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Stevie

    @Gordon, actually I did that first, but mine isn't accurate enough, either :-(

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Stevie

    Hi @Gordon,

    So I did some more measurements with the suggested capacitor. I used a 1 uF capacitor which should be plenty for smoothing out things a bit (actually the Puck can run for a couple of seconds off the capacitor before losing the connection to the web UI).

    The measurement for the connected state is basically the same (~270 uA). The measurement for the advertising / disconnected state is smoothed out but still looks pretty weird: It stays at 12 uA for a bit, then ramps up to 80 uA within 3.5 s and then goes back to 12 uA again witinh 3.5 s. So we basically have a 7 second loop where something is happening. Without the capacitor it is similar, just a bit more fluctuating. Note that this happens with an empty Puck (reset() + save()) as well as with one which is watching a pin. Basically the same behavior. So something is going on every 7 seconds which draws quite a bit of power when advertising.

    I also tried to switch off the bluetooth sender/receiver using NRF.sleep(). That does something: I immediately lose the connection from the web UI. But apparently it still advertises bluetooth. It still has this power cycle described above. And I can connect to it later using the web UI. I checked if the NRF.sleep() somehow causes a reset by lighting the LED on reset for a second. So that does not happen. So apparently either the bluetooth is not switched off completely. Or it is switched on again.

    This is with the latest firmware.

    Any ideas?

    UPDATE: It seems the disconnection from the IDE triggers a reset of the bluetooth stack (in jswrap_bluetooth.c, bleUpdateServices). So that explains why the NRF.sleep() does not switch off the bluetooth stack. It only works when there is no bluetooth connection. I called it from a timer and then the current goes down to ~12 uA. But still once in 7 s it goes up to 24 uA. This is independent from a setWatch on the button.

    UPDATE2: When setting the advertisement interval to 750 ms, then the power fluctuation is much faster. When setting the advertisement interval to 2 s, then it fluctuates between 12 uA and 30 uA every 2 seconds. That's kind of what @Gordon also measures. So my conclusion is that the fluctuation is somehow connected to the Bluetooth advertising interval. Maybe there is something wrong with the initialization of the Bluetooth stacked which is fixed when calling NRF.setAdvertising(...)? Interestingly enough with that setting even in the NRF.sleep() state the power consumption seems to be still fluctuating between 12 uA and 24 uA every 7 seconds.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Stevie

    I will try the idea with the capacitor, great suggestion! I will post the new results when I have done that. But again this could also be related to measuring error.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Stevie

    @allObjects: I looked into the Online Profiler a while ago, but it does not help that much. It does not allow to specify watches on pins and timers and so on. Maybe they do not have much influence on the power consumption. For other microcontrollers, they do. But that's what I am trying to find out.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Stevie

    I did some measurements of my own using a similar method. Basically I 3D printed a CR 2032 replacement and put a cable on top and below the replacement.
    The numbers I measured are a bit higher than what you mention, about 270 uA when connected, 8 uA when not advertising and have the watch set. When advertising the current fluctuates so strongly that it's difficult to judge. But it seems in the same ballbark of the 20uA.
    So all in all it's all the numbers are in the same ballpark and the differences in measurements could be measurement errors on my side. So battery lifetime seems to be excellent and I can now measure how much current different applications would draw.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for Stevie

    Thanks, sounds perfect! I will try it out!

Actions