Searching \ for '[pic]:CCP Capture mode' 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/microchip/devices.htm?key=pic
Search entire site for: 'CCP Capture mode'.

Exact match. Not showing close matches.
PICList Thread
'[pic]:CCP Capture mode'
2003\02\23@014948 by Scott Dattalo

face
flavicon
face
AFICT, there's a race condition that exists in the CCP modules. Consider
this:

 - Event occurs and is captured in CCPR1L and CCPR1H
 - The contents of CCPR1L are read.
 - Another event occurs and is captured in CCPR1L and CCPR1H
 - The contents of CCPR1H are read.

In other words, while reading/processing a captured event, another event
is captured. There's a two instruction cycle window of vulnerability. The
only way to avoid this vulnerability is to:

a) Turn off the CCP module before reading CCPRxL and CCPRxH registers.
b) Program the clock source that's being captured to have a frequency
   half the speed of the instruction execution frequency.

In case (b), you could do something like this (with interrupts disabled)

loop:
       MOVF    CCPR1L,W                ;
       MOVWF   TC_CaptureLo            ;Save the time when the last edge
       MOVFF   CCPR1H,TC_CaptureHi     ;was captured
       CPFSEQ  CCPR1L                  ;If an event occurred between
        bra    loop                    ;reading Hi/Lo then try again

   ; now we have a good 16-bit sample

Are there any other reasonable ways to avoid this?

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@021104 by Robert Rolf

picon face
Read the low register a second time? If it was different from the first
reading you had a 2nd capture during your vulnerable window and would repeat
the process. If you are getting captures so quickly you don't have
time to read both low and high value, aren't you running too close to the
edge?

This same idea as read high, low, high is also a good idea when reading
timers to ensure that your high byte was not read after the low byte
overflowed.

Robert

Scott Dattalo wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@025331 by Scott Dattalo

face
flavicon
face
On Sun, 23 Feb 2003, Robert Rolf wrote:

> Read the low register a second time? If it was different from the first
> reading you had a 2nd capture during your vulnerable window and would repeat

That's exactly what I proposed in the option (b). (Go back and re-read
the original message paying special attention to the code).

> the process. If you are getting captures so quickly you don't have
> time to read both low and high value, aren't you running too close to the
> edge?

I was mostly speaking hypothetically. My point was simply that *if*
another unexpected event occurs, it will corrupt the reading. But speaking
practically, it's not uncommon to get glitches right around the transition
of an event. In addition, the time when the capture registers are read
can be quite far away from the time the event actually occurred. The worst
case scenario I suppose is when the event occurs while the code is
currently in an interrupt routine. I could easily see 20 instruction
cycles fly by between the event and the reading of the register.

Now in my particular case, I'm reading pulses coming off of an RF
receiver. It just so happens that when the RF transmitter (on the other
end) is not transmitting the RF receiver begins hallucinating. The AGC
circuit begins to push the low background noise up to where it can be
seen. This causes erroneous short-lived glitches. When the RF transmitter
is transmitting, there's plenty of signal and the pulses are nice and fat
and easy to read.

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@040011 by Jinx

face picon face
>   - Event occurs and is captured in CCPR1L and CCPR1H
>   - The contents of CCPR1L are read.
>   - Another event occurs and is captured in CCPR1L and CCPR1H
>   - The contents of CCPR1H are read

Can you make use of the prescaler in your application ? Are you
trying to measure individual pulses ?

This might sound a little off the wall (as I'm not sure what your
intention is or the nature of the pulses), but how about an
external flip-flop + SPDT to deflect the second pulse away from
the CCP pin (or maybe off to another PIC for its own CCP)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@073549 by Roman Black

flavicon
face
Scott Dattalo wrote:

> Are there any other reasonable ways to avoid this?

1. Make use of the CCP interrupt, as soon as the capture
occurs you can handle the condition in int code.

2. Increase the capture prescaler to 2x pulse or 4x pulse,
giving you a lot more time to check and save the capture
before the next one happens.

3. If you don't want another interrupt try a called
(polled) function that checks the CCP flag and saves the
value. This only costs 1 inst (call x) which can be placed
throughout your other code.

All these rely on having enough time to keep on top of
things and handle the capture before the next one. If you
are risking a race condition it might be time for a
re-think of total timing allocation. :o)
-Roman




{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@083451 by Olin Lathrop

face picon face
Scott Dattalo wrote:
> Now in my particular case, I'm reading pulses coming off of an RF
> receiver. It just so happens that when the RF transmitter (on the other
> end) is not transmitting the RF receiver begins hallucinating. The AGC
> circuit begins to push the low background noise up to where it can be
> seen. This causes erroneous short-lived glitches. When the RF
> transmitter
> is transmitting, there's plenty of signal and the pulses are nice and
> fat
> and easy to read.

What a coincidence.  Right now I'm working on a project that interprets
four manchester encoded bit streams with one PIC, two of them coming from
RF receivers with 10KHz bit rate.  These receivers also produce gibberish
when there is no RF to receive.  This is common because the receiver
cranks up its gain and adjusts its detection threshold to the average
level, so it will always produce a digital signal that is high about half
the time.

I'm dealing with this by simply ignoring it.  Any RF protocol I've ever
seen has a preamble to let the receiver adjust its gain and center value.
The packet following then contains a checksum and maybe a signature.
These are intended to make is impossible (within acceptable probability)
for random noise to be interpreted as a valid packet.  So my interrupt
routine will continue to measure the hash, but the result won't make it
thru the packet detection and validation code.

It is a good idea to analog filter the signal from the receiver to limit
the maximum frequency of the hash to avoid eating up too many processor
resources.  A simple R-C or R-C-R-C is fine.

By the way, I'm not using the CCP module for this.  I'm trying to cram all
this into a 18F1320 (or 18F1220 if I get lucky), which only has one CCP
module.  The high/low priority interrupt structure of this part makes the
whole thing possible.  These are nice little chips.  Finally a small low
cost 18F with a decent peripheral set.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@090635 by michael brown

picon face
Scott Dattalo wrote:
{Quote hidden}

GIGO  ;-)  Maybe it's time to use a faster crystal?  I'm guessing that
you are either monitoring an HF sideband signal, or an unsquelched FM
receiver.  Maybe a DSP audio processor between the radio and the PIC
might help to clear things up?  Another idea that comes to mind is to
immediately disable the Capture upon entry into your subroutine, this
should cut the critical area down to around 10 clocks max as opposed to
20.  Maybe some more filtering on the input data to eliminate spikes?
Without knowing more about the signal you are trying to process, I'm
pretty much shooting in the dark, but hey it's the piclist.  ;-)

Michael Brown
Instant Net Solutions
http://www.KillerPCs.net

"In the land of the blind, he who has one eye is king"

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@123040 by Scott Dattalo

face
flavicon
face
On Sun, 23 Feb 2003, Jinx wrote:

> >   - Event occurs and is captured in CCPR1L and CCPR1H
> >   - The contents of CCPR1L are read.
> >   - Another event occurs and is captured in CCPR1L and CCPR1H
> >   - The contents of CCPR1H are read
>
> Can you make use of the prescaler in your application ?

Sure.

>                                                          Are you
> trying to measure individual pulses ?

Yes.


Basically I'm measuring the pulses in a 10kHz pulse stream (100 uS period)
where a pulse 25uS wide is a zero and a pulse 75uS wide is a one. It's
relatively easy to do with the CCP module. But while writing the code, I
realized that there is this race condition that exists. To me it really
doesn't matter.  It just means that occasionally I'll misread one pulse
width and get an error. The communication link is robust enough to recover
from this error (because, in general RF links can be noisy and need
adequate mechanism to recover against errors).

OTOH, if there's a potential error source that can be identified, then
there may be a potential fix to remove it. I can't see any *simple* fix.
I'm not going to add extra hardware, and I really don't care to add extra
inefficient software like the looping solution I proposed. However,
another simple solution could be to inhibit the CCP module:

   MOVF    CCP1CON,W             ;Save the current CCP mode
   CLRF    CCP1CON               ;Disable the CCP module so that
                                 ;no new events are captured while
                                 ;we're reading the last captured event
   MOVFF   CCPR1L,TC_CaptureLo   ;Save the time for the last edge
   MOVFF   CCPR1H,TC_CaptureHi   ;
   MOVWF   CCP1CON               ;Restore the CCP mode
   BCF     PIR1,CCP1IF           ;Clear any spurious interrupt.

Has anyone tried something like this?

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@124423 by Ned Konz

flavicon
face
On Sunday 23 February 2003 05:33 am, Olin Lathrop wrote:
> By the way, I'm not using the CCP module for this.  I'm trying to
> cram all this into a 18F1320 (or 18F1220 if I get lucky), which
> only has one CCP module.  The high/low priority interrupt structure
> of this part makes the whole thing possible.  These are nice little
> chips.  Finally a small low cost 18F with a decent peripheral set.

I'm so happy to see their focus on smaller packages. I especially like
the 3-pin SOT-23 version (see
http://www.microchip.com/1010/pline/picmicro/category/embctrl/8kbytes/devices/18f1220/index.htm)

Package Options
18 PDIP, 20 SSOP 208mil, 28 SOIC, 28 QFN, 3 SOT-23

--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@124425 by Dave Tweed

face
flavicon
face
Olin Lathrop <spam_OUTolin_piclistTakeThisOuTspamEMBEDINC.COM> wrote:
> What a coincidence.  Right now I'm working on a project that interprets
> four manchester encoded bit streams with one PIC, two of them coming from
> RF receivers with 10KHz bit rate.  These receivers also produce gibberish
> when there is no RF to receive.  This is common because the receiver
> cranks up its gain and adjusts its detection threshold to the average
> level, so it will always produce a digital signal that is high about half
> the time.
>
> I'm dealing with this by simply ignoring it.  Any RF protocol I've ever
> seen has a preamble to let the receiver adjust its gain and center value.
> The packet following then contains a checksum and maybe a signature.
> These are intended to make is impossible (within acceptable probability)
> for random noise to be interpreted as a valid packet.  So my interrupt
> routine will continue to measure the hash, but the result won't make it
> thru the packet detection and validation code.

There's a risk with this approach, depending on how distinctive your packet
preamble is, that you'll lose legitimate packets because of noise. It works
like this:

A burst of noise that looks like a packet preamble comes along. This kicks
off the packet assembly process, which proceeds to collect the packet data
and checksum. During the data portion of this presumed packet, the preamble
for a *real* packet occurs, but is treated as data. By the time the
decoding process ends and discards the bad packet, most of the legitimate
packet has already gone by, and you miss it.

There are a couple of cures for this. If the protocol is such that the
packet preamble cannot legitimately appear in the body of a packet (some
kind of out-of-band signal), you can watch for it at all times and abort
decoding a bad packet if another preamble comes along. Another approach is
to buffer all of the incoming raw data and do a sliding-window search for
valid packets (but this tends to be both memory- and CPU-intensive). A
third approach would make use of any AGC or RSSI (receiver signal strength
indicator) signal from the receiver to "qualify" the data for the packet
decoding process.

-- Dave Tweed

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@125339 by jim barchuk

flavicon
face
Hi Scott!

> Basically I'm measuring the pulses in a 10kHz pulse stream (100 uS period)
> where a pulse 25uS wide is a zero and a pulse 75uS wide is a one. It's
> relatively easy to do with the CCP module. But while writing the code, I
> realized that there is this race condition that exists. To me it really

[snip]

>     MOVF    CCP1CON,W             ;Save the current CCP mode
>     CLRF    CCP1CON               ;Disable the CCP module so that
>                                   ;no new events are captured while
>                                   ;we're reading the last captured event
>     MOVFF   CCPR1L,TC_CaptureLo   ;Save the time for the last edge
>     MOVFF   CCPR1H,TC_CaptureHi   ;
>     MOVWF   CCP1CON               ;Restore the CCP mode
>     BCF     PIR1,CCP1IF           ;Clear any spurious interrupt.

Oh, OK, pulse stream. In your first post you didn't mention if you were
sampling analog or digital data, but 'race condition' did imply digital.
If analog I would have mentioned Nyquist, which I thought about because
you also mentioned you were thinking about 'more than twice' the incoming
rate.

In any case this mentions your fix exactly:
http://www.circuitcellar.com/pastissues/articles/ball127/text.htm. That's
AVR but still spot on. (Nearer the bottom of the page.)

I didn't like the 'loop until no interupts' because if they came in too
fast for whatever reason you'd have no choice but to just sit there and
wait for them to settle. Or worse, they -don't- settle. 'Whatever' meaning
a problem elsewhere that causes things to run totally out of control. But
if they do, then...

> The communication link is robust enough to recover from this error
> (because, in general RF links can be noisy and need adequate mechanism
> to recover against errors).

...that will deal with it.

Have a :) day!

jb

--
jim barchuk
.....jbKILLspamspam@spam@jbarchuk.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@133804 by Olin Lathrop

face picon face
{Quote hidden}

Yes, you're absolutely right.  But in this case each packet starts with a
sufficiently long string of 1s such that at least 5 in a row are visible
after the receiver AGC has settled.  This is followed by a special 16 bit
signature that doesn't contain more than 2 1s in a row.  The chances of
random noise looking like valid preamble and signature are low enough that
it's quite acceptable to miss a valid packet in the very rare case it is
preceeded by such noise.  Each packet also has a 16 bit CRC at the end, so
the probability that random noise looks like a valid packet is vanishingly
small.

I didn't design the protocol.  If I had, I might have done away with the
signature altogether, and spent fewer bits using bit stuffing or whatever
to guarantee that more than a certain number of consecutive 1s never occur
in a valid packet.  Then it would be easy to keep a counter at all times
and abort back to the start of the loop if more than that number of
consecutive 1s was ever received.  But the spec is what it is, and is out
of my control.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@135223 by Scott Dattalo

face
flavicon
face
On Sun, 23 Feb 2003, Olin Lathrop wrote:

{Quote hidden}

This my situation exactly too. My bit stream is only 32 bits and prefaced
with a 14-bit preamble of 7 1's followed by 7 zeroes. The packets come
from many different sources simultaneously - collisions will happen. Each
source emits its packet over and over and uses a PRN generator determine
the time for the next transmission interval. Instead of CRC's though, I
use modified hamming codes. There's not much space in 32-bits for a CRC...

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@135847 by Scott Dattalo

face
flavicon
face
On Sun, 23 Feb 2003, Roman Black wrote:

> Scott Dattalo wrote:
>
> > Are there any other reasonable ways to avoid this?
>
> 1. Make use of the CCP interrupt, as soon as the capture
> occurs you can handle the condition in int code.

Yep. That's what I do already.

> 2. Increase the capture prescaler to 2x pulse or 4x pulse,
> giving you a lot more time to check and save the capture
> before the next one happens.

Yep. That's one of the solutions I proposed too. The only problem is that
a little bit of resolution is lost.

> 3. If you don't want another interrupt try a called
> (polled) function that checks the CCP flag and saves the
> value. This only costs 1 inst (call x) which can be placed
> throughout your other code.

I prefer the interrupts. (especially since there are a bazillion other
things happening).


> All these rely on having enough time to keep on top of
> things and handle the capture before the next one. If you
> are risking a race condition it might be time for a
> re-think of total timing allocation. :o)

Your's and everyone else's solutions are quite reasonable. The main
purpose for me posting the question was to determine if there was an
oversight on my part with regards to the behavior of the CCP modules. I
think now I can conclude that there is not an oversight, and that there is
a potential gotcha with CCP modules operating in capture mode.

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@150147 by Peter L. Peres

picon face
One trick you can do is to use a FEC code and raise the correction bits
ratio until you get an acceptable error ratio for your application
(knowing that zero error rate is not an available option).

Wrt out of band signalling (as Dave Tweed has said), the easyest is to use
a break in the transmission between packets. A noise burst would have the
same effect however .... Another is to use start or sync pulses of
different duration then those in the normal data. These two methods are
the most used ones, usually in combination with FEC or CRC in the packets.

Once you understand that there is no way to get 100% error free data no
matter what you do, it's all a matter of tradeoff between what you can use
and what you can afford. The FEC code has the advantage that you do not
need a SQ control (the BER tells you that) and you can up the ratio of fec
bits as much as you want (or can afford). I used FEC 3/8 using a table and
breaks (actually the tx side worked only when keyed) followed by a short
sync burst to settle the simple comparator data slicer for carrier current
c. and it works fine.

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@150355 by Dmitriy A. Kiryashov

picon face
Greetings Scott.

What if the first pulse you've captured is noise/wrong pulse?
You lock onto it and miss another one which is right.

Why not filtering approach or correlation ?


WBR Dmitry.


Scott Dattalo wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@170252 by Igor Pokorny

flavicon
face
Hello Dmitry,

you mentioned correlation. Do you know some methods how to do this with
PICs.?  I would like to do PLL of the incoming signal very much (300 to 500
Hz for about 100 to 300 miliseconds) but I am not able to find any algorithm
that would be able to filter a signal and/or to synchronize ADC by a proper
way.

Igor

{Original Message removed}

2003\02\23@180151 by Peter L. Peres

picon face
Correlation: A simple way is to XOR incoming data with data-to-be-tested
and count the 1's in the result. The fewer 1's the better the correlation.
XOR is modulo-2 multiply without carry out (or in) and one (the?)
correlation function is Fc=SumOf|Ai*Bi|. XOR produces this result when Ai
and Bi are binary bits, but the sum is zero for high correlation because
the carry in the XOR multiply is lost. In this case Fc=0 means 'all bits
caused carry' (which was lost). Otherwise one would use an analog
multiplier to check for correlation with analog signals, and aim for high
Fc (not zero). Notice that in a binary XOR correlator an all 1's result
means input and reference are 180 degrees out of phase, or complementary.

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@193954 by Dale Botkin

flavicon
face
Dave Tweed <picspamKILLspamDTWEED.COM> said:

> Olin Lathrop <.....olin_piclistKILLspamspam.....EMBEDINC.COM> wrote:
> > What a coincidence.  Right now I'm working on a project that interprets
> > four manchester encoded bit streams with one PIC, two of them coming from
> > RF receivers with 10KHz bit rate.
8<
{Quote hidden}

8<
> There are a couple of cures for this. If the protocol is such that the
> packet preamble cannot legitimately appear in the body of a packet (some
> kind of out-of-band signal), you can watch for it at all times and abort
> decoding a bad packet if another preamble comes along. Another approach is
> to buffer all of the incoming raw data and do a sliding-window search for
> valid packets (but this tends to be both memory- and CPU-intensive). A
> third approach would make use of any AGC or RSSI (receiver signal strength
> indicator) signal from the receiver to "qualify" the data for the packet
> decoding process.

I've been working with this for a while now...  RF Manchester encoded packets
coming in at random times using a recevier that is not (and cannot be)
squelched.

I used a Microchip app note dealing with their Keeloq products (TB045,
http://www.microchip.com/1010/suppdoc/appnote/all/tb045/index.htm), and
translated that into C code for a state machine that runs from a timer
interrupt.  The ISR executes at about 10x the data bit rate.  I could go into
great detail, but the app note is really pretty good (and the code is for a
customer, so I can't share too much).  Basically it watches for any glitch of
any sort - a missing transition when there shouldn't be one, or an extra
transition where none is expected.  If anything whatsoever isn't right, the
state machine resets to the "watching for preamble" state.

So far the results have been excellent.  Of course you might miss a packet;
this is a fact of life with any RF or IR protocol.  If you need guaranteed
delivery of each packet, you will need to do it with transceivers at each end
and some sort of ACK from the receiving end.  In my particular case I'm just
watching for beacon and command packets that are repeated regularly, so losing
a packet is not a big deal.  Reliability would be another layer.

Dale

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@195914 by Olin Lathrop

face picon face
> I used a Microchip app note dealing with their Keeloq products (TB045,
> http://www.microchip.com/1010/suppdoc/appnote/all/tb045/index.htm), and
> translated that into C code for a state machine that runs from a timer
> interrupt.  The ISR executes at about 10x the data bit rate.  I could go
> into great detail, but the app note is really pretty good (and the code
> is for a customer, so I can't share too much).  Basically it watches for
> any glitch of any sort - a missing transition when there shouldn't be
> one, or an extra transition where none is expected.  If anything
> whatsoever isn't right, the state machine resets to the "watching for
> preamble" state.
>
> So far the results have been excellent.  Of course you might miss a
> packet; this is a fact of life with any RF or IR protocol.  If you need
> guaranteed delivery of each packet, you will need to do it with
> transceivers at each end and some sort of ACK from the receiving end.  In
> my particular case I'm just watching for beacon and command packets that
>  are repeated regularly, so losing a packet is not a big deal.
> Reliability would be another layer.

I'm attacking it a little differently.  I've got two 10KHz and two 1KHz
manchester streams to decode simultaneously.  I just can't sample at 100KHz
and still have any cycles left for the decoding and other logic.  Instead I
use two of the INT interrupts of the 18F set to high priority to measure the
time between edges.  Things are scaled so that the maximum valid time
between edges fits into 7 bits.  The rising/falling edge indicator gets
stuffed into the 8th bit, and the byte gets pushed onto a FIFO for that
stream.  The 1KHz edges get measured similarly by using low priority
interrupts.  This keeps the measurement jitter for the high speed streams
down.  Foreground code then decodes the 4 FIFO streams as it gets around to
it.  This is done in one piece of code that has 4 pseudo-threads running in
it.

Worst case I have a little over 200 cycles average per edge, of which 45 are
used in the interrupt to capture and measure the edge.  The remaining 155
cycles per edge average sounds like enough to do the decoding.  I've worked
out most of that but am only about 1/3 done writing it.  I should know in a
few days how well everything worked together.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\24@001728 by Scott Dattalo

face
flavicon
face
On Sun, 23 Feb 2003, Olin Lathrop wrote:

> I'm attacking it a little differently.  I've got two 10KHz and two 1KHz
> manchester streams to decode simultaneously.  I just can't sample at 100KHz
> and still have any cycles left for the decoding and other logic.  Instead I
> use two of the INT interrupts of the 18F set to high priority to measure the
> time between edges.  Things are scaled so that the maximum valid time
> between edges fits into 7 bits.  The rising/falling edge indicator gets
> stuffed into the 8th bit, and the byte gets pushed onto a FIFO for that
> stream.  The 1KHz edges get measured similarly by using low priority
> interrupts.  This keeps the measurement jitter for the high speed streams
> down.  Foreground code then decodes the 4 FIFO streams as it gets around to
> it.  This is done in one piece of code that has 4 pseudo-threads running in
> it.
>
> Worst case I have a little over 200 cycles average per edge, of which 45 are
> used in the interrupt to capture and measure the edge.  The remaining 155
> cycles per edge average sounds like enough to do the decoding.  I've worked
> out most of that but am only about 1/3 done writing it.  I should know in a
> few days how well everything worked together.

Interesting.

My bit stream is a little different. Instead of Manchester encoding, my
stream is On/Off encoding. Manchester is better. As I said before, the
pulse stream is ~10kHz. The width of the pulse dictates 0's and 1's. At
10kHz, the pulses are coming in at a rate of 1 every 100 uS. 25uS wide
pulses are zeroes and  75uS wide ones are ones. For Manchester encoding
at the same data rate, the narrowest pulse is only 50uS.

I decided to use the CCP module instead of a polling interrupt. I first
program the CCP module to capture every rising edge. When I capture a
rising I subtract from that the time I captured for the last rising edge.
This gives the time between rising edges and should be about 100uS. After
a rising edge is captured, I reprogram the CCP module to capture every
falling edge. When I capture one I subtract from it the time of the last
captured rising edge. This gives the pulse width.

Once the pulse time and pulse width are known, then it's trivial to
calculate 0's and 1's and validate the data. So far, the code takes about
20 cycles per edge. (But more code is still needed..)

Here's the portion that processes rising edges:

       MOVFF   CCPR1L,TC_CaptureLo     ;Save the time when the last edge
       MOVFF   CCPR1H,TC_CaptureHi     ;was captured

       BTG     CCP1CON,CCP1M0          ;Toggle the polarity we'll capture
next.

       MOVF    TC_LastRisingEdgeLo,W   ;Compute the time since the last
       SUBWF   TC_CaptureLo,F          ;rising edge
       MOVF    TC_LastRisingEdgeHi,W   ;
       SUBWFB  TC_CaptureHi,F


  ;; Rising edge. Save the time for this rising edge.

       MOVF    TC_CaptureLo,W          ;Save the time captured for this
       ADDWF   TC_LastRisingEdgeLo,F   ;rising edge. if  X = new - old
then
       MOVF    TC_CaptureHi,W          ; old + X = old + (new- old) =
new.
       ADDWFC  TC_LastRisingEdgeHi,F   ;


  ;; At this point, TC_CaptureHi:Lo = the Bit time
  ;; and TC_LastRisingEdgeHi:Lo = the capture time for the edge that
cause
  ;; this interrupt. Now we need to validate the Bit Time and the pulse
  ;; width.

That's 13 cycles, but there's a little more processing that is not ready
to be shown (i.e. it ain't done yet).

4osc cycles / instruction / (10MHz * 4[pll]) ==> 0.1uS per instruction. 20
instructions per edge corresponds to about 2uS or roughly 10% of the
narrowest pulse expected. Or for 32 pulses, which is 64 edges the percent
of time spend processing is 2us/edge*64edges / (100us/pulse * 32 pulses) =
2% of the CPU's time.

I've pretty much decided to not worry about the CCP Capture race condition
because in my case it just so happens if the CCP module is capturing a new
edge while I'm processing the last edge then it's noise. If I make a
mistake processing noise, then oh well, who cares? If the noise is
mistaken as data, then the alledgedly bad data bits still have to make it
through an error correction checker.

Scott

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@001736 by Scott Dattalo

face
flavicon
face
On Mon, 24 Feb 2003, Peter L. Peres wrote:

> Correlation: A simple way is to XOR incoming data with data-to-be-tested
> and count the 1's in the result. The fewer 1's the better the correlation.
> XOR is modulo-2 multiply without carry out (or in) and one (the?)
> correlation function is Fc=SumOf|Ai*Bi|. XOR produces this result when Ai
> and Bi are binary bits, but the sum is zero for high correlation because
> the carry in the XOR multiply is lost. In this case Fc=0 means 'all bits
> caused carry' (which was lost). Otherwise one would use an analog
> multiplier to check for correlation with analog signals, and aim for high
> Fc (not zero). Notice that in a binary XOR correlator an all 1's result
> means input and reference are 180 degrees out of phase, or complementary.

See:

http://www.dattalo.com/technical/theory/dtmf.html

Here the pulse stream "decoded" is a 50% duty cycle square wave. In the
real code implementation, it's actually faster to perform sequences of:

   BTFSC   port,bit
    INCF   Fc

Instead of performing a sequence of XOR's

For frequency decoders, you really need quadrature sampling.
Fortunately, only 3/4'ths of the time is spent sampling and 1/4'th spent
processing. (Sampling all 8 DTMF freqeuncies simultaneously is
challenging!)

Scott

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@032515 by so-8859-1?Q?Ing_Igor_Pokorn=FD?=

flavicon
face
Great site.

Thank you.

Igor

-----Original Message-----
From: pic microcontroller discussion list [@spam@PICLISTKILLspamspamMITVMA.MIT.EDU]On
Behalf Of Scott Dattalo
Sent: Monday, February 24, 2003 6:09 AM
To: KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
Subject: Re: [pic]:CCP Capture mode


On Mon, 24 Feb 2003, Peter L. Peres wrote:

{Quote hidden}

See:

http://www.dattalo.com/technical/theory/dtmf.html

Here the pulse stream "decoded" is a 50% duty cycle square wave. In the
real code implementation, it's actually faster to perform sequences of:

   BTFSC   port,bit
    INCF   Fc

Instead of performing a sequence of XOR's

For frequency decoders, you really need quadrature sampling.
Fortunately, only 3/4'ths of the time is spent sampling and 1/4'th spent
processing. (Sampling all 8 DTMF freqeuncies simultaneously is
challenging!)

Scott

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@045535 by Mike Singer

picon face
Scott Dattalo wrote:
> For frequency decoders, you really need quadrature sampling.
> Fortunately, only 3/4'ths of the time is spent sampling and
> 1/4'th spent processing. (Sampling all 8 DTMF freqeuncies
> simultaneously is challenging!)
...
> I decided to use the CCP module instead of a polling interrupt.
> I first program the CCP module to capture every rising edge.
> When I capture a rising I subtract from that the time I captured
> for the last rising edge

Olin Lathrop wrote:
> I'm attacking it a little differently.  I've got two 10KHz and two
> 1KHz manchester streams to decode simultaneously.  I just
> can't sample at 100KHz and still have any cycles left for the
> decoding and other logic.  Instead I use two of the INT interrupts
> of the 18F set to high priority to measure the time between edges.

  Let me take part in the combat. I have a secret mortal weapon:
"Free-running counters".
Variation with external parts:
Let us assume that we have external clock 40 MHz and some
very simple circuit that passed this 40 MHz to Timer1 when
input (Manchester) line is low; and passed 40 MHz to Timer3
when input line is high.
Let the Timers be configured as asynchronous counters.
The code should poll counters (don't know if CCP Capture
interrupts wok in asynchronous mode).
Transitions from one state to another are those when value
of one counter corresponds to Manchester period (or two)
and value of another approaches one or two period values.

  No interrupt's code overhead (saving context, disabling/enabling
interrupts etc), no interrupts fired by noise (noise is integrated).
Is this expected to beat 100KHz barrier?

  Hope the idea is not stupid (or is stupid enough to be interesting).

Mike.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@052649 by erholm (QAC)

flavicon
face
A bit of-topic, but...

Have you thought of that,
when using handheld remotes (for e.g. a TV set), and the
betteries are beginning to run low, most people begin to
press *harder* on the keys to get a connection...

Probably more of a behavioural science questions
then an electronic question :-)

Jan-Erik Soderholm.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@063326 by Russell McMahon

face
flavicon
face
> Have you thought of that,
> when using handheld remotes (for e.g. a TV set), and the
> betteries are beginning to run low, most people begin to
> press *harder* on the keys to get a connection...
>
> Probably more of a behavioural science questions

Also a reflection of 'what the market will bear" design. Such controllers
almost invariably use PCB pattern switches with a rubber membrane with
conductive material that is pressed onto the PCB to make contact. Real
switch failures may often in fact be addressed by pressing harder or
"working" the switch. So pressing harder when the battery is expiring is a
logical action. Adding a key click/beep would provide confidence for such
low cost switches. But probably costs too much :-).



       RM

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@083022 by Roman Black

flavicon
face
What about detecting the / edge with the capture int,
but don't bother time check/subtract etc.
When you capture a / edge, simply load one of the timers
to 50uS (between your 2 pulse widths) and when that timer
int occurs all you need to do is check the input, which
will give 0 for 25uS pulse and 1 for a 75uS pulse.
You don't need to do any period measurement and it's
very low in cycles. ;o)
-Roman



Scott Dattalo wrote:

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@084856 by Alan B. Pearce

face picon face
>Now in my particular case, I'm reading pulses coming off of
>an RF receiver. It just so happens that when the RF
>transmitter (on the other end) is not transmitting the RF
>receiver begins hallucinating. The AGC circuit begins to push
>the low background noise up to where it can be seen. This
>causes erroneous short-lived glitches. When the RF transmitter
>is transmitting, there's plenty of signal and the pulses are
>nice and fat and easy to read.

Can you get into the receiver to clamp the AGC voltage at a level
that minimises the receiver sensitivity when the transmitter is off?
I am thinking that a simple diode arrangement onto the AGC line could hold
the AGC voltage at a level that minimised the noise pulses out of the
receiver, but still gave sufficient room for the AGC to follow the
transmitted signal when that is on. This would at least give a first
solution to the problem.

As to the business of ensuring the CCP value is correct, I am sure that I
have seen items about this on the PICList in the past, maybe time to check
the archives Scott ?? :)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservEraseMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@085059 by Mike Singer

picon face
Roman Black wrote:
> What about detecting the / edge with the capture int,
> but don't bother time check/subtract etc.
> When you capture a / edge, simply load one of the timers
> to 50uS (between your 2 pulse widths) and when that timer
> int occurs all you need to do is check the input, which
> will give 0 for 25uS pulse and 1 for a 75uS pulse.
> You don't need to do any period measurement and it's
> very low in cycles. ;o)

Noise sensitive, I suspect.

Mike.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@085949 by michael brown

picon face
Mike Singer wrote:
> Roman Black wrote:
>> What about detecting the / edge with the capture int,
>> but don't bother time check/subtract etc.
>> When you capture a / edge, simply load one of the timers
>> to 50uS (between your 2 pulse widths) and when that timer
>> int occurs all you need to do is check the input, which
>> will give 0 for 25uS pulse and 1 for a 75uS pulse.
>> You don't need to do any period measurement and it's
>> very low in cycles. ;o)
>
> Noise sensitive, I suspect.

I'm not saying that it isn't, but how would this method be any more
noise sensitive than using the capture/compare module?  It seems to me,
that with oversampling, this would be far less susceptable to noise than
using the capture feature.

michael brown

"In the land of the blind, he who has one eye is king"

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@091201 by Alan B. Pearce

face picon face
>There are a couple of cures for this. If the protocol is such
>that the packet preamble cannot legitimately appear in the body
>of a packet (some kind of out-of-band signal), you can watch
>for it at all times and abort decoding a bad packet if another
>preamble comes along.

I have a feeling that this is the sort of thing that HDLC/SDLC protocol does
by bit stuffing. The requirement is that within a valid message there can be
a maximum of 4 (IIRC) 0 or 1 in a row, and if that occurs then a bit of the
opposite state is "stuffed" into the message, irrespective of the state of
the next bit. However the preamble is deliberately set up to violate this
rule for the reasons given in the quote.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@100912 by Mike Singer

picon face
Agreed.

Mike.

michael brown wrote:
{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@102124 by Scott Dattalo

face
flavicon
face
On Tue, 25 Feb 2003, Roman Black wrote:

> What about detecting the / edge with the capture int,
> but don't bother time check/subtract etc.
> When you capture a / edge, simply load one of the timers
> to 50uS (between your 2 pulse widths) and when that timer
> int occurs all you need to do is check the input, which
> will give 0 for 25uS pulse and 1 for a 75uS pulse.
> You don't need to do any period measurement and it's
> very low in cycles. ;o)

This is a good suggestion but it has two problems. First, there will be
some jitter between when the edge occurs and when the timer is started.
The CCP module records the value of the timer at the point when the event
occurs. The second problem is that it really isn't any faster. In fact, by
the time you get through initializing/unloading/reloading the counter
you'll have spent just as much time with the roll over arithmetic. Neither
of these issues really affect my application too much.

In my application, I'm actually measuring the width of two pulses
referenced to the same edge:

___--------------___________________________---------------
 |<---- P1 --->|
 |<-------------------- P2 -------------->|
 ^             ^                          ^
 +- start timer|                          |
               + read timer               |
             Read timer and restart timer +

The Read/Restart action happens at every rising edge. Instead of loading a
timer and monitoring the interrupt, I could envision code like this:

   movff    tmrxLo, RisingEdgeLo    ; save the current time
   movff    tmrxHi, RisingEdgeHi    ; save the current time

   clrf     tmrxLo                  ; Restart the timer
   clrf     tmrxHi

That's about twice as fast as reading the Captured time and using rollover
arithmetic. Well, okay it's not quite twice as fast since there is some
processing that I didn't show that takes advantage of the carry bits in
the arithmetic. But instead of loading the "count down" timer with a
16-bit value and waiting for the interrupt, I think it's faster to start
and restart the timer at the edges.

In the snippet of code I posted earlier, I didn't show the falling edge
processing. It's very similar to the rising edge processing, but takes
only 9 cycles instead of 13. But for grins, here it is:

process_falling_edge:

       MOVFF   CCPR1L,TC_PulseLo       ;Save the time when the last edge
       MOVFF   CCPR1H,TC_PulseHi       ;was captured

       MOVF    TC_LastRisingEdgeLo,W   ;Compute the time since the last
       SUBWF   TC_PulseLo,F            ;rising edge
       MOVF    TC_LastRisingEdgeHi,W   ;
       SUBWFB  TC_PulseHi,F

Again, for the timer start/restart approach, the falling edge processing
is about twice as fast as this.

Scott

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservSTOPspamspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@165453 by William Chops Westfield

face picon face
> Have you thought of that,
> when using handheld remotes (for e.g. a TV set), and the
> betteries are beginning to run low, most people begin to
> press *harder* on the keys to get a connection...

Some remote-like devices are (were?) actually powered through the keypad.
V+ would get wired on one side of the switches, with the other connected
to controller inputs AND sorta "wired-or" to the circuits power.  That
way the device only uses power when you push a button...

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservSTOPspamspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@171120 by Peter L. Peres

picon face
On Mon, 24 Feb 2003, Jan-erik Soderholm (QAC) wrote:

*>A bit of-topic, but...
*>
*>Have you thought of that,
*>when using handheld remotes (for e.g. a TV set), and the
*>betteries are beginning to run low, most people begin to
*>press *harder* on the keys to get a connection...
*>
*>Probably more of a behavioural science questions
*>then an electronic question :-)

Yes but it could be used to light (flash) a LED or a piezo to request
battery change. Conductive rubber contacts will have a different average
resistance when pressed down hard than when pressed lightly. A micro could
observe the last 100-200 presses and request the user to push easier
and/or suggest service using this data ;-) (alternate solution: remote
controller squeaks 'ouch! that hurt!')

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\24@184712 by Olin Lathrop

face picon face
> Yes but it could be used to light (flash) a LED or a piezo to request
> battery change. Conductive rubber contacts will have a different average
> resistance when pressed down hard than when pressed lightly. A micro
> could observe the last 100-200 presses and request the user to push
> easier and/or suggest service using this data ;-) (alternate solution:
> remote controller squeaks 'ouch! that hurt!')

Or have the button squeeze a piezo to produce the power to send the IR
code.  Then pushing harder really does make it go farther <g>.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2003\02\25@042527 by Roman Black

flavicon
face
Olin Lathrop wrote:
>
>Conductive rubber contacts will have a different average
> > resistance when pressed down hard than when pressed lightly. A micro
> > could observe the last 100-200 presses
>
> Or have the button squeeze a piezo to produce the power to send the IR
> code.  Then pushing harder really does make it go farther <g>.


Just to get eccentric with the idea, what about
using a piezo gas-oven lighter as a remote control's
power source? It might be hard to rectify and filter
those 10kV+ spikes but it's a renewable power source
you can buy for a couple of dollars and puts out some
decent energy... ;o)
-Roman

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu>

2003\02\25@062036 by Alan B. Pearce

face picon face
>Just to get eccentric with the idea, what about
>using a piezo gas-oven lighter as a remote control's
>power source? It might be hard to rectify and filter
>those 10kV+ spikes but it's a renewable power source
>you can buy for a couple of dollars and puts out some
>decent energy... ;o)

I hope you already have a version of the Black switch mode
regulator that gives 5V out from 10kV in :)))))))))))))

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamKILLspammitvma.mit.edu>

2003\02\26@020704 by Dmitriy A. Kiryashov

picon face
That's binary correlation. Can be done many ways actually
counting/changing or not sign/msb bit. Really depends what
you want to get from it.


"Peter L. Peres" wrote:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\02\26@021343 by Dmitriy A. Kiryashov

picon face
Hi Igor.

I've done work for PICs using correlation with fixed frequencies.
For PLL I was using hardware but it seems possible to do it in
software as well for low frequencies. ( the same ideas )

In your case highest frequency is 500 Hz which is 2 mSec
With 20 MHz PIC and (for say) 20% of PIC time used for PLL
software you'll have 2000 clocks per sine period.
Looks quite doable.

With what speed the primary frequency can change ? ( Hz/sec)
Do you need just to decode what is frequency/amplitude/phase
or you really need to do PLL on that ? The more details the better


WBR Dmitry.


Igor Pokorny wrote:
{Quote hidden}

> {Original Message removed}

2003\02\26@143550 by Peter L. Peres

picon face
On Tue, 25 Feb 2003, Roman Black wrote:

*>Olin Lathrop wrote:
*>>
*>>Conductive rubber contacts will have a different average
*>> > resistance when pressed down hard than when pressed lightly. A micro
*>> > could observe the last 100-200 presses
*>>
*>> Or have the button squeeze a piezo to produce the power to send the IR
*>> code.  Then pushing harder really does make it go farther <g>.
*>
*>
*>Just to get eccentric with the idea, what about
*>using a piezo gas-oven lighter as a remote control's
*>power source? It might be hard to rectify and filter
*>those 10kV+ spikes but it's a renewable power source
*>you can buy for a couple of dollars and puts out some
*>decent energy... ;o)

You do not have 10kV if you put a capacitor across it. It produces about
20mJ. Using Wc=C*U^2/2 and wanting 5V C results:

C=2*Wc/U^2=2*2*10^-2/25~=1500uF.

Use two shottky diodes as rectifiers. And tell us if you zap yourself good
;-)

Peter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\02\26@164251 by erholm (QAC)

flavicon
face
And, if an PIC draws 1 mA, how often do you
have to "ignite" to keep the PIC running ?
:-)
Jan-Erik.

Peter L. Peres wrote : [.....plpspam_OUTspamACTCOM.CO.IL]

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\02\28@041132 by Peter L. Peres

picon face
Unfortunately I was off by a little. A piezo device requires 2kgf to push
down and travel is 1cm. This works out to 0.1mJ, 200 times less than what
I said, and not considering efficiency. The cap should be 200 times
smaller for the same voltage (10uF). With 1mA drain, C=10uF, start 5V and
end voltage 3V the PIC would work for about 20msec. Check my numbers.

Peter


On Wed, 26 Feb 2003, Jan-erik Soderholm (QAC) wrote:

*>And, if an PIC draws 1 mA, how often do you
*>have to "ignite" to keep the PIC running ?
*>:-)
*>Jan-Erik.
*>
*>Peter L. Peres wrote : [TakeThisOuTplp.....spamTakeThisOuTACTCOM.CO.IL]
*>
*>> *>Olin Lathrop wrote:
*>> *>Just to get eccentric with the idea, what about
*>> *>using a piezo gas-oven lighter as a remote control's
*>> *>power source? It might be hard to rectify and filter
*>> *>those 10kV+ spikes but it's a renewable power source
*>> *>you can buy for a couple of dollars and puts out some
*>> *>decent energy... ;o)
*>>
*>> You do not have 10kV if you put a capacitor across it. It produces about
*>> 20mJ. Using Wc=C*U^2/2 and wanting 5V C results:
*>>
*>> C=2*Wc/U^2=2*2*10^-2/25~=1500uF.
*>>
*>> Use two shottky diodes as rectifiers. And tell us if you zap yourself good
*>> ;-)
*>
*>--
*>http://www.piclist.com hint: PICList Posts must start with ONE topic:
*>[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
*>
*>

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

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