David thank you for the input.  I looked over the app note.  They are
suggesting a design with the LTC3440.  This might not be the best solution
for my case.  Currently when in sleep mode with pic, I am down to 24uA @3.6V
and I need to be about 10uA (if at all possible).
The quiescent current for this unit is between 25uA to 40uA which is *way*
too high for my purposes.

However, I got an idea and curious if it would work.  The pic is in sleep
mode for 1500ms, then wakes up for about 20ms (currently this is as low as I
could go) and sleeps.  There is the MCP2120 (min. 2.5V) and TFDU4100 (min
2.7V) on the board.  I only need to power these devices during the 20ms
interval.  What I might be able to do is to power the pic from 3.6V battery
with two diodes, voltage drops to about 2.2V which 16LF628 can handle.
Connect the LTC3440 outputs (with 2.8V) to MCP2120 and the TFDU4100.  I can
then enable the LTC3440 to power the devices and cut the power when done.
This raises two issues for me though:

1. I do not know what will happen between the 2.2V powered pic and 2.8V
powered MCP2120.  Could they still communicate?
2. MCP2120 needs 30ms (max) time when powered down (as opposed to only 1000
Tosc when enabled from a disabled state).  Which is too much time anyways.

So using a voltage regulator would not solve my problem it seems.  My
problems would be solved if I only could get the TFDU4100 and MCP2120 to
sense the dummy wake up characters that I am sending, within a 1ms period
(over 9600 baud).  Then I would not have to worry about going as low as
2.8V!

I appriciate if anyone is *even* reading this long message...

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu