Rising and Falling Edge triggered one-shot

Hi, thanks for the responses.  Give me a moment to study them and I'll respond to every post.  In the meantime, if you know of any good repositories for spice .SUBCKTs or .MODELs or Eagle files or LTCSpice schematics, please point me to em.  thx Ted

> interrupt on pin change? 

Currently, that would require my Bluetooth Bee Standalone v1 (the uC) to remain energized to catch the interrupt, but it's for development.  The final choice of uC is still up in the air, I know some uCs have a low power standby wake on interrupt mode, and I'm open to suggestions like Phil's and yours to make that power savings an intrinsic part of the design if possible.  

Thanks,
  Ted

I've simulated in LTSpice an RC (1Meg,0.5u) input to XOR approach that is simple, cheap, detects both edges, and produces the needed 'one-shot' width to wake up the uC.  Just an RC into the XOR.  Unless it's flawed.  Thanks, Ted

tedj121@gmail.com wrote on 1/13/2018 4:17 PM:
> I've simulated in LTSpice an RC (1Meg,0.5u) input to XOR approach that is simple, cheap, detects both edges, and produces the needed 'one-shot' width to wake up the uC.  Just an RC into the XOR.  Unless it's flawed.  Thanks, Ted

Simulations are rarely real world realistic.  So you need to know where the 
bodies are buried.  In this circuit it will be the noise sensitivity.

A simple approach is to use a FF to hold a state set by the MCU and the XOR 
to detect edges on the incoming pulse.  The pulse edge rises, the XOR wakes 
the CPU, the CPU changes the FF and the wakeup pulse ends.  In essence the 
CPU becomes your delay element.  Picking a FF that is easy to manipulate is 
where the bodies are buried on this approach.  You can use a $0.25 part and 
a pair of pins on the CPU or a bit more complex one wire part (I think a 
dollar?) and a single pin on the MCU.  Can the MCU remember the present 
state of the FF?  If not the $0.25 part will need an input pin to read the 
value or maybe a resistor to allow the FF to drive the data signal when the 
MCU output is tristate.  The one wire solution still only uses one wire.

Multisecond analog delays are asking for trouble in a digital design.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

On 2018-01-13, rickman <gnuarm.deletethisbit@gmail.com> wrote:
> tedj121@gmail.com wrote on 1/13/2018 4:17 PM:
>> I've simulated in LTSpice an RC (1Meg,0.5u) input to XOR approach that is simple, cheap, detects both edges, and produces the needed 'one-shot' width to wake up the uC.  Just an RC into the XOR.  Unless it's flawed.  Thanks, Ted
>
> Simulations are rarely real world realistic.  So you need to know where the 
> bodies are buried.  In this circuit it will be the noise sensitivity.
>
> A simple approach is to use a FF to hold a state set by the MCU and the XOR 
> to detect edges on the incoming pulse.  The pulse edge rises, the XOR wakes 
> the CPU, the CPU changes the FF and the wakeup pulse ends.  In essence the 
> CPU becomes your delay element.  Picking a FF that is easy to manipulate is 
> where the bodies are buried on this approach.  You can use a $0.25 part and 
> a pair of pins on the CPU or a bit more complex one wire part (I think a 
> dollar?) and a single pin on the MCU.  Can the MCU remember the present 
> state of the FF?  If not the $0.25 part will need an input pin to read the 
> value or maybe a resistor to allow the FF to drive the data signal when the 
> MCU output is tristate.  The one wire solution still only uses one wire.
>
> Multisecond analog delays are asking for trouble in a digital design.

yeah, like Jim's circuit but with the microcontroller in the loop in
addition to the flip-flop, that seems pretty solid.


-- 
This email has not been checked by half-arsed antivirus software 

On Thursday, January 11, 2018 at 5:25:54 PM UTC-5, mike wrote:
> On 1/11/2018 1:33 PM, tedj121@gmail.com wrote:
> > Bluetooth Bee Standalone v1
> I only spent a few minutes with google, but going from
> bluetooth bee to the chip specs
> 
> http://electronut.in/atmega168-power-save-mode-and-pin-change-interrupt/
> 
> I'm a PIC person, so have no direct experience here.

Guess I assumed wrong.  Good find.  There is an energy management user library available at the Arduino website.  And an example using it compiles.  Haven't tested it yet, but thanks for giving me another path to explore.  Ted

> why do you need the one-shot when the sensor turns on?

A power enable to the uC long enough for the uC to wake up and get ready for it's little digital day and control continued power to itself.  The sensor indicates a change in condition that must be serviced.

> so, how does ths work when the sensor turns off again - what powers the one-shot?

I was incomplete when I said the sensor being on powers the uC.  Currently, the touch sensor output is ORed with the uC's stay-on bit and with the edge detector's output (which remains on for the wake-the-uC interval).  Three attached collectors of three NPN inverters are tied high at a P-Channel MOSFET gate.

> Doesn't the CPU support a hibernate mode with wake on change for certain 
> pins? Even if it was only for one edge transition then a pair of those 
> pins and a single inverter would get you what you want.
> 
> It seems a bit brute force and crude to start up from cold every time.

See reply to Mike.  Looking into the Enerlib library posted at the Arduino website.  Also, I'm not locked into the Bee (hosting the ATMEGA168), which is for ease of development even as I see that it's time to choose that final uC at this stage.

> It probably isn't worth getting average quiescent current much below the 
> self discharge rate of typical alkaline batteries (ie <5uA). If you were 
> running it off a tiny battery then it might be worth trying harder.

I just have this shweet touch sensor that only consumes 5nA and actually works (with a little shielding).

> > The "standard" approach...
> >
> ><http://www.analog-innovations.com/SED/PulseOnBothEdges.png>

Thanks for that.  Looks good for high speed circuits.  I may not need any memory function and the sensor out directly to an RC (low pass filter) to a Schmidt comparator may fit the bill by supplying both the edge detection function and the one-shot function in a remarkably simple circuit (a resistor, a capacitor and an XOR), whether or not noise becomes an issue as Rick suggests.  Ted

> microfarads,megaohms and a CD4070BE will achieve that, seems an
> unpopular part, but TI is still making them.

I think that's the simplest approach.  I think the R and the C can be tweaked if necessary and still get the same time constant.  Ted