Searching \ for '[PIC] How to work around Phantom Power?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/power.htm?key=power
Search entire site for: 'How to work around Phantom Power?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] How to work around Phantom Power?'
2006\04\09@130635 by Brooke Clarke

flavicon
face
Hi:

I have a 16F54 that's being used to divide a precision 10 MHz frequency
source down to a precision 1 PPS output by using the 10 MHz as the PIC
clock and managing the number of instructions executed.
http://www.leapsecond.com/tools/PPSDIV.ASM

If the DC is applied then the clock input connected it works the way the
code would suggest.  But if the clock is connected before the DC power
is applied strange things happen (LEDs not in the states the code would
suggest).  Then manually grounding MCLR gets things back to normal, but
I don't want to add a START switch if there's a way around the phantom
power problem.

Is there a way to programmatically determine if phantom power has caused
problems?

Thanks,

Brooke Clarke

--
w/Java http://www.PRC68.com
w/o Java www.pacificsites.com/~brooke/PRC68COM.shtml
http://www.precisionclock.com

2006\04\09@132320 by Jan-Erik Soderholm

face picon face
Brooke Clarke wrote :

> But if the clock is connected before the
> DC power is applied strange things happen...Hi !

Any pin going higher then a few 100s of
millivolts above Vdd is against the datasheet.

Make sure that no I/O pin ever can get a
higher voltage then Vdd, including your
10 Mhz clock input.

One way is to clamp the clock signal to Vdd
with a (schottky) diod.

Jan-Erik.



2006\04\09@140912 by Brooke Clarke

flavicon
face
Hi:

I have a 16F54 that's being used to divide a precision 10 MHz frequency
source down to a precision 1 PPS output by using the 10 MHz as the PIC
clock and managing the number of instructions executed.
http://www.leapsecond.com/tools/PPSDIV.ASM

If the DC is applied then the clock input connected it works the way the
code would suggest.  But if the clock is connected before the DC power
is applied strange things happen (LEDs not in the states the code would
suggest).  Then manually grounding MCLR gets things back to normal, but
I don't want to add a START switch if there's a way around the phantom
power problem.

Is there a way to programmatically determine if phantom power has caused
problems?

Thanks,

Brooke Clarke

--
w/Java http://www.PRC68.com
w/o Java www.pacificsites.com/~brooke/PRC68COM.shtml
http://www.precisionclock.com

2006\04\09@151108 by Wouter van Ooijen

face picon face
> If the DC is applied then the clock input connected it works
> the way the
> code would suggest.  But if the clock is connected before the
> DC power
> is applied strange things happen (LEDs not in the states the
> code would
> suggest).

If you can't prevent osc input before power is available I would put
some load on the power line (470 Ohm would be fine - 10 mA) and add an
external brown-out reset chip (TO92 style, microchip has them, plenty of
others too).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\04\09@152724 by Robert Ammerman

picon face
Try capacitively coupling the oscillator input and setting the PIC to XTAL
osc instead of external. You will likely need a couple of resistors to
DC-restore the signal after the capacitor.

Bob Ammerman
RAm Systems

{Original Message removed}

2006\04\09@154536 by Jan-Erik Soderholm

face picon face
(Got this reply personaly, but I see no reason why it
coudn't be on-list.)

Brooke Clarke wrote :

> Maybe I didn't use the correct word "Phantom".
>
> For example the clock signal is a sine wave with 1 volt pk - pk
> (well below Vcc of 5 volts), yet if the clock is connected prior to
> the +5 volts the chip does not work properly.  But if the +5 is
> connected first or MCLR is pulsed low , then all is well.

Yes, but the problem isn't when Vcc is 5V, it's when Vcc is 0 volt.
At *that* time you're violating the "absolute maximum" in the
data sheet, and the processor doesn't startup as it should (but
I guess just about anything could happen since you're outside
of the specs anyway).

Jan-Erik.



2006\04\10@092956 by M. Adam Davis

face picon face
Technically, it's a reset issue caused by power coming from the clock
line.  There are several options that revolve around the following two
fixes:

1) limit power coming from clock line
2) reset the chip properly on power up

The ideal solution will use both.

1) The clock input is sensitive enough that you should be able to put
a 1K or larger resistor in series with it.  This should prevent the
clock line from powering the circuitry through the protection diode as
long as the circuit draws 10mA or more under normal operation.  If it
draws very little current you may need to add a load resistor (470
ohm, 1/4 watt) across the +5 and GND pins of the PIC to pull the
voltage down.  This should prevent the PIC from starting, as the
voltage across the chip should be less than 1.5V.  If you still
experience problems, then  go to a 100ohm resistor across the +5 and
GND lines of the chip.  Worst case this will allow the voltage to go
as high as 0.5V.

2) You can also use a diode to block the current.  Place a diode in
the clock path so it will only sink current, not source it (ie,
current can only go from the PIC to the clock source).  Then use a
pull up resistor on the PIC side of the diode.

3) The next simplest solution would be to use a transistor to buffer
the clock.  A simple PN2222 with a couple of resistors will prevent
the clock from powering the circuit.

4) You can also employ gates inbetween the chip and the clock source.
Many high speed TTL and CMOS gates don't have protection diodes IIRC,
so they shouldn't pass the clock signal to +5 when the circuit is off.
Check the datasheet carefully.

5) On the reset side, a typical solution is to employ a brownout
detector/reset circuit.  These aren't expensive, and you can create a
simple one with a few components if you don't want to buy a packaged
IC.

There are a few application notes on suitable reset circuits from
microchip, usually conisting of a resistor and capacitor.  Make sure
you are following something similar.  For this particular case,
however, you can use a diode to make sure the reset gets no power from
the circuit:

6) From the power supply have one diode going to +5 for the rest of
the circuit.  The reset circuit connects directly to the +5 supply.
Even if the clock line powers the rest of the circuit, the diode will
prevent that from powering the reset circuit, and upon +5V powerup you
should have a clean reset.

Out of all of these, I'd go for #2 first.  This should make your
circuit work as needed.  If not, #6 and #1 together should work very
well regardless of the clock source.

-Adam

On 4/9/06, Brooke Clarke <spam_OUTbrookeTakeThisOuTspampacific.net> wrote:
{Quote hidden}

> -

2006\04\10@170602 by Peter

picon face

On Sun, 9 Apr 2006, Brooke Clarke wrote:

> Hi:
>
> I have a 16F54 that's being used to divide a precision 10 MHz frequency
> source down to a precision 1 PPS output by using the 10 MHz as the PIC clock
> and managing the number of instructions executed.
> http://www.leapsecond.com/tools/PPSDIV.ASM
>
> If the DC is applied then the clock input connected it works the way the code
> would suggest.  But if the clock is connected before the DC power is applied
> strange things happen (LEDs not in the states the code would suggest).  Then
> manually grounding MCLR gets things back to normal, but I don't want to add a
> START switch if there's a way around the phantom power problem.

Couple the clock with a small value capacitor and resistor (e,g, 100pF
and 100 ohms in series) and shunt Vdd and Vss of the pic with 1kohm.
This assumes that the clock has a suitable amplitude (nearly 5Vpp). The
dc recovery is done by the bulk diodes in the PIC.

Peter

2006\04\10@204331 by Brooke Clarke

flavicon
face
Hi Adam:

I tried a couple of your ideas with no luck.  But then started making
measurements of the clock signal to see how big it was and found it to
be much less than 5 and more than 0 volts and so started looking at the
code.  The problem was setting the bits that control the LEDs prior to
the TRIS command.  Once I modified the code all is well.  Thanks for
getting looking in the right place.

Have Fun,

Brooke Clarke

--
w/Java http://www.PRC68.com
w/o Java www.pacificsites.com/~brooke/PRC68COM.shtml
http://www.precisionclock.com

2006\04\11@113622 by M. Adam Davis

face picon face
I'm glad the issue was resolved!

>From the HW engineer:
Blame the software.

>From the SW developer:
Blame the hardware.

You tend to get twice as much blame when you're both!

-Adam

On 4/10/06, Brooke Clarke <.....brookeKILLspamspam@spam@pacific.net> wrote:
{Quote hidden}

> -

2006\04\11@113626 by M. Adam Davis

face picon face
I'm glad the issue was resolved!

>From the HW engineer:
Blame the software.

>From the SW developer:
Blame the hardware.

You tend to get twice as much blame when you're both!

-Adam

On 4/10/06, Brooke Clarke <brookespamKILLspampacific.net> wrote:
{Quote hidden}

> -

2006\04\12@123856 by Peter

picon face

On Tue, 11 Apr 2006, M. Adam Davis wrote:

> You tend to get twice as much blame when you're both!

Yes, but you can keep to yourself what you tell the man in the mirror.

Peter

2006\04\13@044201 by Alan B. Pearce

face picon face
>> You tend to get twice as much blame when you're both!
>
>Yes, but you can keep to yourself what you tell
>the man in the mirror.

Oh, you mean like Leisure Suit Larry, you talk to yourself, and find you
know what you are going to say ...

2006\04\13@143810 by Peter

picon face

On Thu, 13 Apr 2006, Alan B. Pearce wrote:

>>> You tend to get twice as much blame when you're both!
>>
>> Yes, but you can keep to yourself what you tell
>> the man in the mirror.
>
> Oh, you mean like Leisure Suit Larry, you talk to yourself, and find you
> know what you are going to say ...

Yes, but if you live in a 2 1/2nd world country obsessed with security
you could serenade the hidden microphones. Then wait for the clapping
from the surveillance van outside. Or one of the technicians to come
over and tell you what's wrong with your approach ;-)

Peter

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...