Sourcing or Sinking digitalWrite uses 68uA

Good morning! So I am trying to source/sink power to an xBee ZigBee chip using a digital output pin on the Arduino. Normal sleep current is 4.5uA.

pinmode is output
digitalwrite(#,HIGH/LOW);

When I have digitalWrite, my sleep current is 68uA. If I comment out digitalWrite my current is back to 4.5uA.

I looked into pull ups/downs and I thought that that only applies to pinmode-inputs. Anything I am missing?

Thanks all!

What's the input impedance or input current for the ZigBee chip? It doesn't surprise me that it would take some current.

I've never used sleep mode but I'm pretty sure simply waking it up increases current consumption. That's the whole point of sleep mode.... To reduce power consumption...

Presumably the 68uA only happens when the output is in one state - sounds like there is a 100k
internal pull-up or pull-down on the Zigbee. Just call pinMode (..., INPUT) before sleeping.

The digitalWrite is not for the wake up pin. Its for supplying actual operating voltage to the xBee. If I connect the pin directly to VCC/GND instead of using Arduino to do it, I get 4.5uA which is normal.

If I do digitalWrite Input, xBee doesnt work. If I REMOVE xBee all together and use digitalWrite Output pin with nothing connected, I still am drawing that much current while sleeping. Something is happening internally on the MCU

See this tutorial on reducing current consumption during sleep mode. It does matter how you set the I/O pins.

I read that tutorial already. I was able to get it to work but I noticed that the current takes longer to "settle" in sleep than when powering it directly from VCC. I tried a .1uF, 10uF, 100uF caps but that didnt work.

brolly759:
The digitalWrite is not for the wake up pin. Its for supplying actual operating voltage to the xBee. If I connect the pin directly to VCC/GND instead of using Arduino to do it, I get 4.5uA which is normal.

Have you been trying to power an xBee from an Arduino pin? Yes, that will fry the pin nicely I'd have thought.

Yes that is exactly what I am trying to do. Its working fine now, max draw is 36mA and you can set the transmit current to be lower so you are even lower current consumption. No frying. The issue now is that when going from awake to sleep, you can see it takes about a second+ longer for the current to drop quickly than powering the xBee directly from VCC/GND.

Yes that is exactly what I am trying to do. Its working fine now, max draw is 36mA

Bad idea in the long run. You ARE damaging the output pin. Use the pin to switch a high-side PNP transistor instead.

Depending on the resistor I use, With a transistor always on, 2907A, 10K uses 300uA in sleep mode.

brolly759:
Yes that is exactly what I am trying to do. Its working fine now, max draw is 36mA and you can set the transmit current to be lower so you are even lower current consumption. No frying. The issue now is that when going from awake to sleep, you can see it takes about a second+ longer for the current to drop quickly than powering the xBee directly from VCC/GND.

No, you don't understand, you cannot normally get away with this. Either you have no decoupling (and
the ~ 40 ohm output resistance of the Arduino pin means unstable power for the transmitter), or you
have decoupling capacitors (as with xBee?) and you heavily overload the Arduino pin with capacitor inrush
current every time you switch on, eventually degrading/frying the pin. Logic outputs cannot drive large
capacitive loads (100's of pF are OK, 100's of nF is like a short circuit at logic speeds).

Use a transistor or MOSFET to switch the power to the xBee. Usually you'd high-side switch with a PNP or
p-channel device. You'll get sub-ohm impedance and something robust enough to handle decoupling
capacitor inrush (or even soften it). Use a rope to lift the load, not a thin piece of thread.

I would like to do this in a way that does not consume current with passive components.

That is nearly impossible, but with some clever design you can minimize current consumption by the required passive components.