Craig Niederberger wrote:
>
> > To smooth out transitions in the face of noise, it would be helpful to
> > know the range of frequencies monitored.  Why only three cycles?  What
> > does the noise look like.  Somethimes random noise included with the
> > signal will improve detection.
> > Wioth more info I may be able to make suggestions.  What is your
> > response time?  (Sample time to decision time.)
>
> Hi Gus, thanks for the response.
>
> (1) Range of frequencies: about 150 Hz -- 150000 Hz
>
> (2) 3 transitions for one cycle:
>
>         ...........         ..........
>         |         |         |
>         |         |         |
>   ......|         |.........|
>         1         2         3
>
>    Right now, that's all I'm measuring, but the noise is interfering
>    with the signal.  I'm open to any SW/HW suggestion.  The problem is
>    that I'm seeing noise primarily at *low* freqencies, around the edges
>    of each transition.  At high frequencies, the transitions are pretty
>    stable.
>
> (3) The noise looks like jagged high frequencies as the transition edges
>    low freqency signals.
>
> (4) Response time preferably no more than .025 msec.

Craig,

For debouncing the edges you may want to take a look at:
http://www.interstice.com/~sdattalo/technical/software/pic/debounce.html

However, if the high frequency stuff around your low frequency edges is
less than 150kHz, then this software debouncer will not work.

I thought about this "parallel frequency counter" thing for a bit
and thought of something that might be useful for your application
(but probably not for frequency counting in general). Think about
how a counter works. The n'th bit is toggle if all of the n-1 bits
are high and there is a request to count up, otherwise the nth bit
is unchanged. For example

  0101 ==> 0110
bit 0 and bit 1 are toggled
  0111 ==> 1000
bit 0,1,2, & 3 are all toggled

In boolean, we can say that the 4 bit counter is for example:
ABCD. Let's say that I is the input that indicates we want to
increment the counter (when I is high we increment when I is
low the counter remains unchanged). Then the equations can be
written:

  D+ = D ^ I
  C+ = C ^ (I&D)
  B+ = B ^ (I&C&D)
  A+ = A ^ (I&B&C&D)

Now what's neat about this, is that we can handle all eight
inputs simultaneously. In other words, we can allocate/name
a PIC register 'D' and let it hold all 8 of the LSB's, let
'C' hold the next LSB etc. I call these vertical counters
(although there may be a more appropriate name) because if
you view the RAM they occupy as a stack, then the counter
bits are grouped vertically instead of the more familiar
horizontal-single-register way. For a slightly less botched
explanation, check out:

http://www.interstice.com/~sdattalo/technical/software/pic/vertcnt.html

At any rate, we can write:

       MOVF   PORTB, W

  ;debounce ....

  ;with debounced value in W

       XORWF  last_value,W   ;Get the changes from last time
       XORWF  last_value,F   ;Save this sample for next time
                             ;note (A^B)^A == B

       MOVWF  I
       ANDWF  B,W
       ANDWF  C,W
       ANDWF  D,W
       XORWF  A,F

       MOVF   I,W
       ANDWF  C,W
       ANDWF  D,W
       XORWF  B,F

       MOVF   I,W
       ANDWF  D,W
       XORWF  C,F

       MOVF   I,W
       XORWF  D,F

And you can check for rollovers like so with this chunk
just before you increment the counters.

       MOVF   I,W
       ANDWF  A,W
       ANDWF  B,W
       ANDWF  C,W
       ANDWF  D,W

There's another way to implement this vertical counter
that's slightly less efficient, but handles the rollover
case much better. But damn, I'm way too busy now.

Hope this is of some use.

Scott