Sharp pulse on ADC input and NAP

[HankMcSpank]

I have a 12LF1822 running at about 8-10ua in Sleep (the PIC 'LF' variants consume signifiantly less power in sleep, so considering moving over to a PIC that can be had in LF variant. Also, as you point out, the lower the voltage the better)

It's imperative before putting the PIC to sleep, to get all your IO pins & PIC peripherals in the right 'state' to consume the least power while sleeping - I find the best way is studying the associated ciruit it interfaces with, then a massive amount of trial & error while checking the current draw on my DVM! (ie switch off all the uneeded PIC internal peripherals, IO pin TRIS states have the most impact along with pins being set up as analague or not...whilst there are rules of thumb - http://ww1.microchip.com/downloads/e...hapter%202.pdf - I've found the results in the real world to be somewhat random!)

[Bruce]

Hi Anand,

That sounds about right since the comparator & internal Vref use a bit more power than the A/D, but doing it the other way you're going to miss a lot of sensor pulses while it's NAPing for ~18mS.

If this doesn't have to respond 'immediately' when the pulse comes, you could just setup a loop taking A/D measurements while sleeping, wake, look for a value, return to A/D sampling while sleeipng, but you would have to configure the A/D manually, start the conversion, then immediately @ SLEEP.

Use the A/D interrupt to wake it from sleep when the A/D sample is finished. It would be sleeping the majority of the time until the A/D result register indicated a change in voltage.

That would help get the power consumption down with the 12F675. You could also put it to sleep during your high pulse by setting the WDT prescaler, and using the WDT VS a PAUSE 500. Set the pin high, go to sleep, wake-up, clear the pin, return to wait for the pulse.

I'll 2nd the 12LF1822. This part also allows you to enable/disable WDT, and everything on it uses less power than the 12F675.

Run it on an external 32kHz LP oscillator, and use the comparator for wake-up. On wake-up, enable WDT with a prescaler set to 512mS. Take your output high, goto sleep for the duration of the 500mS pulse. Wake up, clear the output, disable WDT, and return to sleep to wait for the comparator wake-up pulse.

That would save a ton of power for a battery app.

[ardhuru]

Hank, Bruce, thats a whole lot of suggestions I can work on to optimize the design. The stress on the low current is, because there IS no battery driving this circuit. Its phantom power tapped off the DSLR's control port as shown here http://www.doc-diy.net/photo/hdr-jack/

Although my app is somewhat different, the powering scheme is exactly as used in the intervalometer project.

I'm going to try everything you guys suggested, one by one, and see if I can get away with using a 12F675 (just beacuse I have a few lying around), and if I cant pare it down enough I guess I'll just have to switch over to an LF part.

BTW, did you notice this guy feeds the Vdd to the controller (Atmel, in this case) thru' the signal pins rather than the proper Vdd pin? Is this desirable/acceptable/reliable? On the pic it did work, but did not reduce the current consumption much.

Will keep reporting back my findings!

Regards,

Anand

[Bruce]

Hi Anand,

If this is just a one-off hobby project, you can probably get by with the minimalist approach of feeding Vcc through an internal protection diode, but I would not call the method desirable/acceptable/reliable for anything I intended to sell as a product.

I would prefer to just add my own diode inline with the Vcc supply if I needed the 0.6V drop.

If you're going to use to use the 12F675, I would go with an external LP 32kHz crystal for sure. That drops your current from Fosc = 4MHz INTOSC at ~500-700uA @ 3V down to ~18-20uA @ 3V.

Then adjust WDT prescaler for whatever delays you need, and have all delays during sleep periods. I/O output levels stay the same during sleep, and that can save a ton of power. If timing isn't critical.

The stress on the low current is, because there IS no battery driving this circuit

If it's operating from the camera battery, which it appears to be, it definitely is battery powered...

[ardhuru]

Okay, that makes a lot of sense. Timings are not at all critical, so it should be a cinch. And the available power already is 3.3 volts DC, no issue there either. I'll try the 32kHz approach. Its just that the 'componentless' version in the URL looked too fascinating.

If it's operating from the camera battery, which it appears to be, it definitely is battery powered...

Absolutely! I meant its own battery. The port control pins are pulled high by 47K resistors internal to the camera, and these are the pins my circuit would have to be powered by.

Thanks again!

Anand

[Bruce]

Its just that the 'componentless' version in the URL looked too fascinating.

I hear you. Yet another reason to grab a couple of 12LF1822. This one can run on the internal 31kHz osc at around 4-22uA @3V.

Looks like a fun project. I liked the other one he linked to for tripping the shutter with the microphone, but was a little sketchy on how they tripped it with thunder from lightning. The sound arrives a "long" time after the flash...

That would be a neat project if you could trip it with the lightning flash VS sound.

Let me know how this works out. I'm curious.

[ardhuru]

Right, then, 12LF1822 seems to be the most painless way to go. Will order a few right away.

About the flash-before-sound, do take a look at the swiss-knife amongst remote shutter controls here http://www.doc-diy.net/photo/smatrig/#thecircuit

Multiple triggers, delay options, the guy does it all.

But I like the idea of my Android doing all the hard work, rather than having a dedicated piece of hardware. I dont do any Android apps development, but what already exists on the net seems to be enough for what I need. These apps drive an IR LED straight from the earphone jack, which is what I'm not happy about. That is the basis of this project; use the asme software, and be able to connect a cable between the Android and the DSLR for a far more robust operation. Gives you remote control, intervalometer, lime lapse and so on. Perhaps a later avatar of the app might use the phone's microphone for sound trigger as well?!

Will definitely report back on conclusion!

Regards,

Anand