Sharp pulse on ADC input and NAP

[ardhuru]

Hi, I have a requirement as follows;

Wait for response on an ADC input; the trigger signal expected is around 1 volt, width of 2 ms. The moment it arrives, output a 500 ms pulse on another pin. Kind of a pulse stretcher (was thinking of using a CMOS 555, but want to avoid components and make it flexible). Very weak power supply available, so maximum consumption to be limited to 40 uA or so.

I tried this code, and it works perfect, except of course the consumption (no load) is around 800 uA.

TEST:;NAP 0
ADCIN 2, LEVEL
IF LEVEL > 5 THEN
DEBUG #LEVEL,13,10
HIGH LED
PAUSE 500
LOW LED
ENDIF
GOTO TEST

I snicked in a NAP 0 command, and it stops working; triggers once in a few events.

The NAP 0 works fine if I manually feed a wider pulse to the input trigger and consumption drops to 30 uA), so I guess its the narrow pulse that doesnt like the NAP command. Since the input transition is way less than 5 volts, I am using the pin as an ADC input.

So my question is, how can this be done best? I'd like to avoid using any extra passive components if I can.

Thanks and Regards,

Anand Dhuru

[mister_e]

I would use a wake on comparator interrupt or pin change with a permanent sleep instead
@ SLEEP

a PIC10F204/206 can wake from a comparator or any pin change, really cheap, would be a perfect choice. Would require only a few lines of code.
http://ww1.microchip.com/downloads/en/DeviceDoc/41239D.pdf

Is it mandatory to supply 5V to your PIC? What's the requirement for the Output pulse amplitude?
Why i'm asking, refer to figure 13-2 and later.

[ardhuru]

Thanks for the fast response, Steve. Funny, I'm using a 12F675, but did think it was an overkill and a 10FXXX would be a fine fit.

Also thought the @ SLEEP would be the answer, but I have to admit interrupts (specially the ADC triggerred ones), are not my Forte. Could you possibly point me in the right direction?

Actually, the supply is 3.3, and the PIC merely needs to pull down an external pin thats held high (also at 3.3) with a very weak pull-up.

For those interested, this is a wired remote for DSLRs that uses a smartphone as a triggering device with s/w thats available free (for Androids for sure, dont know about other platforms)

Regards,

Anand Dhuru

[Bruce]

I have not tested this since I don't have a 12F675, but something like this should work. You might need to tweak the internal CVref settings.

Hook your sensor output to GPIO.1 Vin-. When your sensor outputs 1V (or anything > CVref) it should wake-up from sleep.

If you don't have PBP3 just get rid of the config line, and use what you have.



#CONFIG
__config _INTRC_OSC_NOCLKOUT & _BODEN_OFF & _MCLRE_OFF & _WDT_OFF & _CP_OFF
#ENDCONFIG

DEFINE OSCCAL_1K 1 ' load internal osc calibration value

LED VAR GPIO.2 ' LED output
CmpFlag VAR PIR1.3 ' alias comparator interrupt flag bit
CoutBit VAR CMCON.6 ' CMCON.6 is set while voltage on Vin- > CVref

ANSEL = 0 ' disable A/D
GPIO = 0 ' LED off on POR
TRISIO = %00000010 ' GPIO.1 = input for Vin- comparator, rest outputs
VRCON = %10100111 ' internal CVref enabled, low range.
' CVref = (VR3:VR0 / 24) * VDD.
' with (VR3:VR0) = 7 we have (7/24) * 3.3V
' so internal CVref = 0.9625V
' a voltage > 0.962V on Vin- (GPIO.1) will set COUT,
' set the comparator interrupt flag, and wake us up.
CMCON = %00010100 ' Comparator w/o Output and with Internal Reference

PIR1 = 0 ' clear flags before enabling comparator int
PIE1 = %00001000 ' comparator interrupt enabled.
INTCON = %01000000 ' enable peripheral interrupts for comparator
' global interrupts disabled, so there's no jump to
' an interrupt vector. We're just waking-up from sleep.

TEST:
WHILE CoutBit ' wait for COUT to clear. This clears when the voltage on
WEND ' Vin- falls below the internal CVref
CmpFlag = 0 ' clear comparator interrupt flag bit before entering sleep
@ SLEEP ' should sleep until comparator trips
HIGH LED
PAUSE 500
LOW LED
GOTO TEST
end

[ardhuru]

Bingo, Bruce! My mistake, the trigger amplitude is more like 0.5 volts, so I just edited the VRCON bits and it works like a charm. But, I measure around 200 uA in standby now. Still a HUGE improvement over my earlier 800 uA, but with the NAP I was getting a draw of about 30 uA. Am I doing something wrong?

All above readings are on my breadboard at 5 volts, while testing. When its finalized the circuit will work on 3.3 volts, so I guess the consumption would be reduced significantly.

Regards,

Anand

[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/en/DeviceDoc/01146B_chapter%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...:rolleyes:

[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...:rolleyes:

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...:o

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