Pixl and MDBT42Q deep sleep power figures?

Hello,

The MDBT42Q page says "2.5 - 16V voltage input, 20uA power draw when advertising", as it's got an LDO (the breakout), is that 50µW @2.5V .. 320µW @16V ? Or, at what voltage did you measure 20µA?

In the pixl and the MDBT42Q, can the bluetooth stack and radio be turned off completely for good if not needed, to save power?

In the pixl, can the display be turned on and off when needed? And if so, would the power drop down to MDBT42Q levels (~50µW) with the display off?

Hi,

The MDBT42Q ... is that 50µW @2.5V .. 320µW @16V ?

Yes - it should be basically the same current draw regardless of the input voltage.

In the pixl and the MDBT42Q, can the bluetooth stack and radio be turned off completely

Yes - just NRF.sleep() or NRF.wake(). The BLE stack is still running, but it doesn't cause any wakeups (apart from to calibrate the RTC) if it's not doing anything. The figures from here are probably quite helpful: http://www.espruino.com/Puck.js#power-co­nsumption

In the pixl, can the display be turned on and off when needed? And if so, would the power drop down to MDBT42Q levels (~50µW) with the display off?

Yes - Newer builds (after 1v99) have Pixl.setLCDPower(bool) that you can use. Power consumption isn't as good, but it's better.

Full details at http://forum.espruino.com/conversations/­324612/ but basically:

• Normal Pixl : 216uA
  
• LCD in standby: 66uA
  

Wow, that was fast, thanks!

66uA

That would be at three volts (from the coin cell)?
Or @5V (powered from USB -> LDO)?
Or at the output of the LDO (3.3V)?

Any idea why it's three times more? Perhaps the buttons' pullups or some other thing that's, sort of ~ easily, fixable?

Hey, not that it's bad, in any case!

I believe that's at Vin - so at whatever voltage you use from 4v to 16v.
It may be less from the coin cell.

Looking at the MIC5225 voltage regulator I think that is the issue. It's advertised as 'Ultra-Low Quiescent Current', but then delving deeper, it's actually drawing about 30uA all by itself.

So you could probably replace it with something else, but when the LCD is on it's drawing way more power anyway.

Yep, the MIC5225 of the pixl has a better (~1/2) dropout figure than the MCP1703 in the MDBT42Q breakout, but that "Very low ground current 29µA", if that's that, is not so good.

The MDBT42Q .pdf says a couple µA in sleep mode, is that right?

It also says it can run from 1.7 .. 3.6V, I could run it straight from 2 big D alkalines in series (3 fully charged .. 2V discharged) and remove the LDO, but, will the LCD still be visible with just two volts? What do you think?

Thanks!

Just tested - the LCD is just visible at 2v, but you could use Pixl.setContrast to account for that if you read E.getAnalogVRef.

Hi,
All of this is why I do use LiFePo4 batteries after, as far as possible, any ldo.
You just don't need them as the batteries will go down from 3.6 V to 3.1 V and charging, as I do it, is at 3.65 V max out of the circuit (removing it from the project and charging separately).
This becomes very important when your main power consumption device is finally close to the ldo quiescent amperage...
Now, some peripherals do have an ldo integrated, and it can be a problem as the LiFePo4 batteries wil dye at 3.1 V while the ldo will reduce its supplied voltage by 0.25 V easily. Not to talk about secondary batteries, poorly designed, which are consuming 13 mA almost permanently. Drones don't care much about nA while we do in this case!

Yes the idea is not to use the LDO, unless I can find one with a few nA quiescent current and 100mV dropout voltage.

Gordon, with Pixl.setContrast did you manage to make it fully perfectly visible again, or only somewhat?

Thanks!

Yes the idea is not to use the LDO, even remove it, unless I can find one with a few nA quiescent current and 100mV dropout voltage, in which case I could use 3 alkalines in series.

Gordon, with Pixl.setContrast did you manage to make it fully perfectly visible again, or only somewhat?

Thanks!

Gordon, with Pixl.setContrast did you manage to make it fully perfectly visible again, or only somewhat?

I didn't try. Honestly at some point you're just going to have to buy one and figure this stuff out yourself :)

setContrast itself may not do it, but it is possible to use Pixl.lcdw to set another value which is to do with the drive voltage, and that will almost certainly do it.

Just a note - I discovered a bug in the firmware that leaves the UART RX pin connected as an input inside the chip.

With that fixed (in 2v02 or cutting edge builds), power consumption with Pixl.setLCDPower(0);NRF.sleep() drops to 15uA.

Nice..

Just understood: That means one year on a CR2032 waiting for a button press...
Congratulations!

Hopefully, yes! Looks like the voltage regulator isn't as bad as I thought :)

Honestly it's amazing what just having a 'floating' input on an nRF52 can cost you in terms of power consumption. Hopefully even Puck users will see a noticeable improvement.

Just to get a bit deeper: should the button beeing waited for be a pull-up or a pull-down? At this level of power consumption, any leakage is costly.

I don't really know if that makes a difference. Pull-down (so 1 when pressed) is probably better because ideally you want as much stuff grounded as possible when in idle.

However I think on the nRF52, having pins set as inputs means that whenver the pin changes there is some electrical activity inside the chip which at least partially pulls it out of sleep mode. Basically as long as the pin isn't 'floating' you'll be fine.