You are reading a single comment by @Stevie and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@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.