Searching \ for 'FFT on PIC midrange' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/math/filter.htm?key=fft
Search entire site for: 'FFT on PIC midrange'.

Truncated match.
PICList Thread
'FFT on PIC midrange'
1999\04\08@072331 by ns

flavicon
face
Knowledgeable and experienced PIClisters,

I am 80% finished developing a device which will be used in the
telephony biz.  So far it is very simple, detect a rising voltage, 3
pushbuttons, 3 LEDs, ISD speech chip, some latches and delay circuits.  So
far all in discrete components.

But, in order to be useful to more than about 10% of our customers, we
will have to add two features :
i) Detect LED start/stop flashing and flash rate
ii) Look for a certain 'sound' - using FFT (required for that pesky last
55% of market share)

Part i) is easily solved with a PIC, much experience there, got the
development tools etc.

Part ii) is our dillemma.  The 'sound' can only be described as a 'zzzzip'
tone, increasing pitch, sort of a ramping-up sound.  I guarantee all below
10kHz, probably lower.  The system must recognise the 'zip' and respond
(just set a pin low etc) within about 0.5-1.0 seconds.

Our dilemma is whether to use a low range DSP (say $AUS10 each) or try to
squeeze it on a mid range PIC ($AUS1-3).

*** Can a mid-range PIC handle this?

** If we use a DSP, I assume it can light LEDs and read pushbuttons.
Will we need to use external latches for pushbuttons etc? Can anyone tell
me who is the 'Arizona Microchip' of DSP suppliers? (cheap, no-nonsense)


Thankyou once again,
David.

1999\04\08@073609 by Ross Bencina

flavicon
face
David,


>Knowledgeable and experienced PIClisters,


Sorry, I may not qualify on that count...

>Part ii) is our dillemma.  The 'sound' can only be described as a 'zzzzip'
>tone, increasing pitch, sort of a ramping-up sound.  I guarantee all below
>10kHz, probably lower.  The system must recognise the 'zip' and respond
>(just set a pin low etc) within about 0.5-1.0 seconds.


Have you established (using Matlab etc) that the 'zzzzip' can infact be
accurately identified using an FFT based detection system? Those kind of
ramping waves are not especially suited to FFT because of the time /
frequency tradeoffs involved.

It may be possible to low-pass filter the signal (in the analog domain) and
then analyse zero crossings with the PIC. If the 'zip' is consistent enough,
you may even be able to get away with regression at a low sample rate
(comparison with a stored 'zzzip').

Ross
<spam_OUTrossbTakeThisOuTspamaudiomulch.com>

1999\04\08@080823 by Nigel Orr

flavicon
face
At 21:22 08/04/99 +1000, you wrote:
>I am 80% finished developing a device which will be used in the
>telephony biz.
>Part ii) is our dillemma.  The 'sound' can only be described as a 'zzzzip'
>tone, increasing pitch, sort of a ramping-up sound.  I guarantee all below
>10kHz, probably lower.

If it's in the telephony biz, it had _better_ be lower, or it won't go down
a phone line (ie under 4kHz, instead of 10 ;-) )

>  The system must recognise the 'zip' and respond

The recognizing bit is probably quite easy, but you might need to give us
some more details of what the actual signal is (ramped sawtooth, sine etc)
to get a more detailed answer.  However, whatever you do, the hard bit is
usually rejecting unwanted signals without rejecting your own- the phone
line can be a bit noisy, so you have to be quite flexible in what you
accept, but not so flexible that a cough or normal voice sound contains
something that you detect.  Wouldn't it be possible to use DTMF and a
standard DTMF decoder chip?

>Our dilemma is whether to use a low range DSP (say $AUS10 each) or try to
>squeeze it on a mid range PIC ($AUS1-3).
>
>*** Can a mid-range PIC handle this?

Maybe, but you might need to specify 'this' in a bit more detail.

>** If we use a DSP, I assume it can light LEDs and read pushbuttons.

But will probably need external circuits to do so, like the latches you
mentioned.

>me who is the 'Arizona Microchip' of DSP suppliers? (cheap, no-nonsense)

Possibly Analog Devices (EZ KIT etc), but it _really_ doesn't compare...
DSPs are good at number-crunching, and fast data transfer, but not so hot
on 'bells and whistles'- microcontrollers are closer to the opposite
extreme... you might need one of each...

Nigel

1999\04\08@083942 by Tjaart van der Walt

flavicon
face
Nigel Orr wrote:
{Quote hidden}

What I would do here, is to divide the zzzzip into say,
8 time slices. Count the zero crossings on a fixed
sample time for each of these slices in your ISR. You
will have to pre-scale a bit. Store the result into one
of eight variables in a circular fashion.

In your main routine, you will have to check that all
the values in these eight variables are (significantly)
larger than the value before it, except for one value.
Statistically, the noise should be the same for all the
samples, so it should cancel out when you compare. If
you get a roll-over on one of the values, your pre-scaler
should increase.

You might end up with something like :
Sample1 = 100
Sample2 = 120
Sample3 = 140
Sample4 = 180
Sample5 = 200
Sample6 = 220   <- end of zzzip
Sample7 = 10    <- start of zzzip
Sample8 = 50

Because Sample6 > Sample5 > Sample4 > Sample3 > Sample2 > Sample1 > Sample8 > Sample7,
you can be reasonably sure that you got the zzzzip. You
will need to run your PIC flat cat to get good results.

A Scenix will probably do the job a lot better because
you will be able to count and compare 16 bit values faster
than the PIC can do with 8 bit values.

Let me know how it works.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
.....tjaartKILLspamspam@spam@wasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
| Mobile : tjaartspamKILLspamsms.wasp.co.za  (160 text chars) |
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\04\08@085543 by oyvind.k

flavicon
face
> But, in order to be useful to more than about 10% of our customers, we
> will have to add two features :
> i) Detect LED start/stop flashing and flash rate
> ii) Look for a certain 'sound' - using FFT (required for that pesky last
> 55% of market share)
>
> Part i) is easily solved with a PIC, much experience there, got the
> development tools etc.
>
> Part ii) is our dillemma.  The 'sound' can only be described as a 'zzzzip'
> tone, increasing pitch, sort of a ramping-up sound.  I guarantee all below
> 10kHz, probably lower.  The system must recognise the 'zip' and respond
> (just set a pin low etc) within about 0.5-1.0 seconds.

I'm assuming the sound is kind of a frequency sweep. If this is
transmitted on a phone line only frequencies below 4 kHz will get
through, so we're probably talking of a sweep from, say, 100Hz to
4kHz.

You could use a frequency-to-voltage converter chip and an A/D to
look for ramping voltages, for instance.

Depending on the duration of the sweep you may be able to low-pass
filter the output of the f-to-v converter to reject some noise.

It may also be possible to use a zero crossing detector and just
count pulses with the PIC, but you will need to know exacty what your
signal looks like, and you will have to do some clever pulse
discrimination software. Speech, for instance, will generate false
zero crossings.

But to be more precise you need to supply more information on this
sound.

> Our dilemma is whether to use a low range DSP (say $AUS10 each) or try to
> squeeze it on a mid range PIC ($AUS1-3).
>
> *** Can a mid-range PIC handle this?

If you're talking FFT, no.


_______________________________________________
¯yvind Kaurstad, .....oyvind.kKILLspamspam.....safetel.no

Safetel AS, P.B. 405
N-4067 Stavanger, Norway
Tel: +47 51 81 78 80, Fax: +47 51 81 78 93

1999\04\08@094745 by mlsirton

flavicon
face
Hi,

On  8 Apr 99 at 21:22, EraseMEdlionsspam_OUTspamTakeThisOuTacs.itd.uts.edu.au wrote:
<snip>
> ii) Look for a certain 'sound' - using FFT (required for that pesky last
> 55% of market share)
<snip>
> Part ii) is our dillemma.  The 'sound' can only be described as a 'zzzzip'
> tone, increasing pitch, sort of a ramping-up sound.  I guarantee all below
<snip>

Assuming your zzzip is a frequency sweep starting at a low frequency
and ending at a higher, what you are trying to do is detect a
sequence of tones.

So you don't need a complete FFT just the power corresponding to the
frequency you are trying to detect, you can calculate this with
less CPU power than a full FFT.

Another option would be to have a set of digital band-pass filters
(FIR or IIR) corresponding to your set of tones - Just start with the
first filter and when you have detection proceed to the next.
CPU power required is relative to the number of taps on the filters.

Hope this helps,
Guy

1999\04\08@134748 by Richard Martin

picon face
Your problem, the 'zippp' sound is not something FFT technology
is particularly good at solving, even if it were 'free' (which
it isn't on PIC's). Better solutions come from the domains
of FIR filters (real cheap <computationally>) on PICs, or
<next> the whole world of 'wavelets'. Both of these can be
computationally much easier than FFT, and are more matched
to the 'non-stationary' zippp you need. Unfortunately
they aren't as accessable <IMHO>  theoretically to those
of us weaned on LTI systems theory.

I'm (among too many other things) interested in PICs and
efficient algorithms for finding "zipppps" <more formally
'chirps'> for many sensor apps. If you mail me directly
I will 'blatther at length' to you on this. Going off line.....

A "joke" from many years ago in DSP (following the old IBM
saw) is that nobody ever got fired for 'buying' FFTs in the
DSP world <<no longer the case>>.

R.M.M.

1999\04\08@135746 by Gerhard Fiedler

picon face
At 14:47 04/08/99 +0200, ¯yvind Kaurstad wrote:
>You could use a frequency-to-voltage converter chip and an A/D to
>look for ramping voltages, for instance.
>
>Depending on the duration of the sweep you may be able to low-pass
>filter the output of the f-to-v converter to reject some noise.
>
>It may also be possible to use a zero crossing detector and just
>count pulses with the PIC, but you will need to know exacty what your
>signal looks like, and you will have to do some clever pulse
>discrimination software. Speech, for instance, will generate false
>zero crossings.

isn't a f-to-v chip more or less the same (in the functionality) as zero
detector plus counting pulses?

another possibility would be a pll.

ge

1999\04\09@093417 by Chris Eddy

flavicon
face
David wrote;

> Part ii) is our dillemma.  The 'sound' can only be described as a 'zzzzip'
> tone, increasing pitch, sort of a ramping-up sound.  I guarantee all below
> 10kHz, probably lower.  The system must recognise the 'zip' and respond
> (just set a pin low etc) within about 0.5-1.0 seconds.

David;I agree with many of my coleagues, that you can tempt fate and look at
zero crossings.  I have attached a code chunk below that does just this.  It
ran on a 12C671 at 4MHz.  On that project, I monitored the tip and ring volts
and current and derived a bunch of line data from it.  This part would track
the frequency present on the ring line.  An earlier version of this code
actually tracked the crossings of the ring voltage and current with a pair of
readings, one above the zero cross and one below.  Then the four readings went
through a chunk of math and derived the phase lag between the two.  The goal
was to detect phase on the ring voltage.  It worked on the bench, but in
reality, the ring current is quite small, and there was not enough signal to
get a zero cross, so that feature was abandoned.

So this piece of code is all that is left of the original goal.  It will catch
the same edge every time it crosses zero.  It is called after every 8 bit
analog read, which is driven by the timer interrupt.  You must do code that
determines peak to peak and thus zero cross threshold, also make a 16 bit
counter in the timer interrupt.  You might also watch the signal level, and
below a certain point, cut off the reading, lest you get random readings in
the noise.  By the way, there is a flag that is set when the 16 bit counter
rolls that tells this code to discard a reading.  Otherwise you would corrupt
a reading based on rollover.  An AC_PERIOD value comes puking out of the
routine.  The rest is a cake walk!

Chris Eddy
Pioneer Microsystems, Inc.

((sory about the caps.. it's a bad habit that I never shook))
RING_VOLTS_ZERO_CROSS
; TRACKS ZERO CROSSINGS FOR CALCULATING FREQUENCY.
; IF THE READING TOGGLES ZERO CROSS, TRACK
; SPLIT BASED ON SIDE OF ZERO WE'RE ON.
BTFSS RING_V_ZERO_SIDE
GOTO RING_VZC_3
RING_VZC_1
; WE WERE ABOVE ZERO, LOOK FOR GOING LOW.
; LOOK FOR GOING BELOW THE MID POINT
MOVFW RING_VRAW
ADDLW ZERO_CROSS_GAP
BTFSC STATUS,C
GOTO RING_VZC_5
SUBWF RING_VMID,W
BTFSS STATUS,C
GOTO RING_VZC_5
; CHANGE OF STATE DETECTED!
BCF RING_V_ZERO_SIDE
; SAVE DATA FROM THIS PAST CYCLE.....
; IF COUNTER ROLLED DURING CYCLE, DON'T SAVE.
BTFSS VALID_RING_PERIOD_TRACK
GOTO RING_VZC_6
MOVFW RING_CROSS_1
SUBWF PHASE_CLOCK_1,F
MOVFW RING_CROSS_0
BTFSS STATUS,C
INCFSZ RING_CROSS_0,W
SUBWF PHASE_CLOCK_0,F
; SHIFT THE ANSWER BY FOUR SO WE CAN GET 0-100Hz
BCF STATUS,C
RRF PHASE_CLOCK_0,F
RRF PHASE_CLOCK_1,F
BCF STATUS,C
RRF PHASE_CLOCK_0,F
RRF PHASE_CLOCK_1,F
; IF MSW NOT ZERO, ZERO OUT (ABOUT 3.9Hz)
MOVFW PHASE_CLOCK_0
BTFSS STATUS,Z
CLRF AC_PERIOD
MOVFW PHASE_CLOCK_0
BTFSS STATUS,Z
GOTO RING_VZC_6
MOVFW PHASE_CLOCK_1
MOVWF AC_PERIOD
RING_VZC_6
; THEN CLEAR COUNTERS TO GET DATA FROM COMING CYCLE.....
BSF VALID_RING_PERIOD_TRACK
MOVFW PHASE_CLOCK_0
MOVWF RING_CROSS_0
MOVFW PHASE_CLOCK_1
MOVWF RING_CROSS_1
GOTO RING_VZC_5
RING_VZC_3
; WE WERE BELOW ZERO, LOOK FOR GOING HIGH.
MOVFW RING_VMID
ADDLW ZERO_CROSS_GAP
SUBWF RING_VRAW,W
BTFSS STATUS,C
GOTO RING_VZC_5
; CROSS DETECTED, CHANGE STATE
BSF RING_V_ZERO_SIDE
RING_VZC_5
RETURN

1999\04\09@111442 by tmariner

flavicon
face
Hello David,

I would do some sort of correlation on your signal, beginning with a target
frequency that is the first encountered and then raise the frequency target
at the suspected frequency increase rate. Then fail and start again if the
correlator gets out of band during the sweep or if insufficient samples come
in during a given time period.

A 4 MHz Pic should be able to keep up with everything up to 10 kHz and still
do all the rest of the processing provided one brings it in on an interrupt
pin. If you construct your history for the correlator correctly, you should
have good immunity to intervening noise.

Tom

> {Original Message removed}

1999\04\09@151914 by Richard Martin

picon face
A Nickle Tour at 'poor man' DSP.

<Note to wizzards: This is not a 'juried' paper submission>

A near optimal detector for non-stationary but deterministic
signals ( a fancy way of putting a 'zippp') is to cross correlate
them with a 'model' of themselves. ['Cross correelate means
roughly to do a point by point multiply of SigA(t) by SigB(t)
at each time t and sum (accumulate) the results. This 'Multiply
And Accumulate' is one function optimised is all DSPs. Then
if we can do this over a set of time (phase) shifts,. the 'winner'
(largest sum) is likely the 'zippp' and the shift says when.

PICs don't like to multiply so fast, but if the 'model' is itself
stored clipped to 1s and 0s , this becomes an ADDITION problem,
or better +1s and -1s then the MAC sums tend to self bound.

If you are further clever you can 'intertweave' the summing/shifting
process to run blindingly fast. Often with negligible memory.

This process has many 'faces', sometimes called 'synchronous
detection'. I've been using tricks like this for many years
for an array of 'DSP' problems. On dumb/slow processors.

<For wizzards; the paper would be "FIR and IIR Filter
Implementation Using Binary-Valued Coeficients" or hopefully
something more obscure>

Like much stuff there is some 'deep' theory under all this. <"Deep"
means someone got a PhD for it sometime.>

A handy and common use is to 'crosscorellate' a suspected
sinusiod with a binary 'boxcar' model of itself (and itself
shifted 90 degrees. This can be done 'on the fly' using
essentially 'NO' memory, it's a pretty good 'filter' whose
properties are well understood; and it's REAL cheap!.

R.M.M.

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