Powering / control power of sensors / peripherals by Espruino pins

The purpose of this conversation is to focus on this subject to collect ideas and various applications in one spot rather than in the individual projects and conversations. If a specific project is already going into details for great lengths, feel free to just post a summary with a good picture that 'sells' the reference and keeps the conversation 'juicy'...

Espruino boards are known for running for ever on a battery with low duty cycles of full operation.

This makes Espruino boards very suitable for wearable products, because the battery can be relatively small and light weight, and therefore the wearable is very comfortable to ware - very wearable.

Other applications are remote, difficult to reach or sealed devices that have to take once in a while a measurement, temporary store the value(s), and may be, transmit them on demand or in bundles on a schedule.

Even if the devices have a sleep or deep sleep mode, they consume power. Some circuits use voltage dividers that draw constantly current when device is powered. It makes though no sense to keep things alive in down cycles - between periods of activity.

Espruino hardware and firmware makes it very easy to control power consumption by the application code, and circuits can be built with equally low power consumption that can wake up Espruino on adhoc / external events - not just internally scheduled events.

An example with thorough data and discussion of it is to be found in this conversation about GPS powered by Espruino pin(s) - pics attached (regarding time line: second graph had separate, own first graph... looking at the shown first graph with power on and finding one fix is inconsistent with the 6 minutes and 15 seconds to go to the 2nd fix make no sense shown in the second graph).

1 Attachment

@user106970 mentioned to apply power to GPR sensor for a health app of sorts in the reference conversation about Please post what you're working on!. To keep this reference or pointer conversation concise, I started this thread.... and also move my comments from there to here (@user106970 may do so as well to provide a fluid reading experience to the forum consumer).

My response to @user106970 thought about about powering the sensor by the microcontroller itself is:

@user106970, take a look at GPS powered by Espruino pin(s). It all depends how much current you need... in the end it may be simpler to have a FET in place. The small offset of Ground could probably be accustomed by some gate circuitry - if even needed. Just make sure you switch all communication pins including signal ground pin to input / high impedance before powering off... otherwise they may destroy the sensor device - or at best - keep it half alive. If it is not working, think of a polarized or 2 step relays (Marklin/Lionel reverse switching unit): a pulse is required to switch between two states or a changing the polarity of the coil feed. Two pins could be able to do so... or four - two paired (I do though not know what transients the collapsing magnetic field creates and may destroy the mc if directly connected - a FET H Bridge may overcome that... but adds more and more components).

To clarify about the high impedance: pinMode(PinReference,"input"); - making it pull-down or pull-up is counter productive since it may even draw more power than when in operation (@user106970: PinReference is not a string but (like) a 'variable' pointing to the pin object... it can be an actual 'variable' that is assigned with the pin reference beforehand - a good practice to do in the beginning of the code to make code easier to move onto different pins and even boards - that may require to use totally different pins).

Sat 2019.12.28

'It all depends how much current you need...'

and that my friends is the secret. E = I/R and P = IE

I originally made a comment #135 regarding powering external devices from the micro itself. My take is to allow the $1 part to take the heat dissipation, protecting the $30 micro. I made my forum comment and moved on.

three hours later

I remembered a comment made on the power dissipation when the voltage demand has a higher voltage input, that caused me to perform a Google search.

forum #3 post Pico Supply Voltage

sidebar

Should I mis-interpret the datasheet, feel free to correct me. I'll own up and eat crow. Used to it as we have our share of road kill here in the mid-west. I grew up on tube theory and had to improve my TTL skills and transition into electronics with extra evening schooling. This was back in the, (gulp) seventies, a time before TTL, 7400's and $10 555's, $0.22/gal leaded gasoline, gourmet coffee was a nickel, beer was a dime, microwave ovens were just available under $1000, we had a black and white TV, color too expensive, cable was five years on the horizon, had a party line (shared with neighbor) with a wired pay-per-call phone, one could get a free C cell or 9V battery at Radio Shack monthly without an in-store purchase, CPM was king as the PC/DOS would make it's debut in a decade, the Internet wasn't even a concept, cell phone technology we read about in Dick Tracy comic books and twenty years into the future. I read George Orwell's 1984 a decade before it's title would become mainstream. I digress . . .

off sidebar

Now, my comments are not to dis-credit the efforts established by @allObjects, but rather to inform as to why checking the datasheet should be a normal part of our projects development. See the article in #2 post ' GPS powered by Espruino pin(s)' for an excellent overview of how to power an external module, using the GPIO pins of the Espruino device itself. As that article uses the Espruino Pico, we'll stick with that for the sake of this post discussion.

p.60 and p.68

ref http://www.espruino.com/datasheets/STM32F401xD.pdf

If we look at the online docs for a Pico,

https://www.espruino.com/Pico

we are able to confirm we have a STM32F401CDU6 device. On p.132 we are able to deduce we have a 'U' type device which leads us to understand we able to dissipate a maximum of 625mW or 0.625 Watts.

p.132
U = UFQFPN
p.60
625mW

Performing some simple maths, we are able to connfirm:

P=IE

I = P/E 0.625 / 5v = 0.125A or 125mA

0.625 / 12 = 0.052 or 52mA

p.68
38 mA all peripherals enabled

which conservatively is where @Gordon arrived at the 40mA draw. Post #4

So, it can be seen that as the voltage across the device goes up, the ability for that device to supply the needed current goes down, at the maximum allowable current/power dissipation. At full output, this Pico would be passing a quarter of an amp or disspiating over half a Watt of power!!

We all know that heat is a number one destroyer of compents, and I'd rather see (and unsolder a three pin device) the low cost regulator take the punishment, rather than risk the more expensive, more pins microcontroller.

Design time and cost limits will finallize the design. Gravity and Mother Nature always win.  Ohm's law it is . . . .

'It all depends how much current you need...'

@Robin,

I = P/E 0.625 / 5v = 0.125A or 125mA

it is not that simple, because not all of the current goes into the chip is burned in the chip... because it would not be able to do 160mA... (some have a limit of 120mA) and it is not 5V but based on 3.3V. If all would be burned up in the chip, the pins would not drive anything anymore either. The average of 40mA is the running chip... no real loads applied to pins. It is less with lower clocking, and higher w/ higher clocking. Voltage drop - voltage across the pin and supply - when sourcing - or ground - when sinking - and the current make up for the heat to dissipate. The limit is not only because of the package but also how fat the bonding wires are... For that reason it is specified that at all times all supply and ground pins have to be connected. Power and ground is provided to the chip on different areas.

I was checking the the GRS sensor schema, and it does use 4.7k+4.7K voltage divider to define the '0-line' considering 3.3V and Ground rails as + and - feed of the op amp - which puts a constant draw of 0.35mA. The op amps (4) themselves consume about 0.7mA according to data sheet -http://www.ti.com/lit/ds/symlink/lm324-n.pdf - and is practically independent of the supply voltage. Even if I'm off by factor 10 with these numbers, it is safe to drive the GRS sensor with Espruino PICO pins. For the NRF52832 - Puck.js, Pixl.js, BLE MDBT42Q Bluetooth Module and breakout board the numbers look a bit different: https://infocenter.nordicsemi.com/pdf/nRF52832_PS_v1.1.pdf und 20 GPIO — General purpose input/output (p.155) - I see the numbers are lower for source and sink - but should still be sufficient to drive the GRS breakout board.

Thanks for your help everybody. Using D1 seems to work fine - although now, rather than using the grove device, I've also found this project:

https://gnomezgrave.com/2015/01/02/gsr-using-arduino/

...which also seems to work fine on 3.3V and has the advantage of being so simple that one can solder all the components into the cable (the insulation is drying as we speak, but had it working fine with the puck.js via breadboard!).

With 3.3v I make the maximum draw through the resistors to be 0.016 mA. Maximum draw through the skin (assuming 1kOhm when wet) is 3.3mA, so very low power.

@user106970

really slick and lean solution...

Be though aware that any excessive statics may push your BLE device over the edge since it is now directly connected to the 'outside'. With proper sequence of 'connecting', I see though no issue (in regard to attached drawing):

• 1. Touch and hold 'touch 1 - g / GND - first
  
• 2. Touch and hold 'touch 2 - a / Analog input - second
  
• 3. Touch and hold 'touch 3 - 3.3 V or analog output pint - third
  
• 4. Let go 'touch 1' - g / GND - fourth
  
  

You may flip 3. and 4. to avoid 'current go thru body'.

Furthermore, your BLE device has to be floating: no (other galvanic) connection to the body (not even via a possible power supply line) - last but not least for safety reasons.

1 Attachment

Sat 2020.01.11

The last two responses #5,#6 were more to conclude the original discussion post #132

http://forum.espruino.com/comments/15038676/
Home >> Official Espruino Boards >> Puck.js, Pixl.js and MDBT42
Please post what you're working on!
Posted on Tue 6th, December 2016

That's OK - the puck.js is battery powered so doesn't have any external power supply.

I don't think I need to be worried about current from the puck going through my body - even if I made the electrodes sharp enough to penetrate skin in two points (which I think brings body resistance down to about 500 ohms) we're still only talking 6.6mA from a 3.3v battery.

Your point about static is appreciated (I must admit I've been very lax about the way I handle arduinos, compared to the paranoia with which I handle the insides of PCs!)

Does touching the ground pin first do anything in this situation (ie when there is no proper route to earth?) Or are you talking about touching a "proper" earth such as a nearby radiator pipe before attaching the device?

Since your device is battery powered, and most likely will not have connection to real earth ground,. touching of real earth may amount to nothing. And even when grounded, touching ground of your device is good enough.

Thanks!