Searching \ for 'Extracting a Doppler signal in the presence of noi' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=extracting+doppler
Search entire site for: 'Extracting a Doppler signal in the presence of noi'.

Truncated match.
'Extracting a Doppler signal in the presence of noi'
1999\04\09@204106 by

I am constructing a PIC based system to display speed in MPH as a function
of the Doppler frequency from an X band radar antenna.  This application is
similar to the familiar roadside radar speed displays, but is intended for
sports/entertainment purposes.

The conversion factor is 31.398 Hz per MPH. I plan to measure the period
over a few cycles and, either by implementing an inverse math function, or
some clever lookup scheme, derive the BCD data for the display.  Resolution
needed is 1 MPH.

I would appreciate any insights, shortcuts or alternatives to this plan, but
even more so, some ideas on dealing with the following complication:

These systems are very often used in an environment where there is a
constant background interference signal, which is generated by a large
air-moving fan.  (The fan keeps an inflatable structure standing.)  This
interference signal is more or less constant, but varies from one
installation to another as a function of the fan type, rotation speed, etc.
The range of interference frequencies is generally between 1500 Hz (which
displays as about 47 MPH) to 2700Hz (which displays as about 84 MPH.)
Unfortunately, this range lies right within the frequency band of interest,
which ranges from about 10 MPH (320 Hz) to 150 MPH (4800 Hz), so it can not

Any ideas as to how this signal can be automatically sampled, and then very
selectively filtered out before the Doppler signal gets to the display
circuitry, would be very much appreciated.  In my mind, the only thing that
makes this possible is the fact that the interference signal is always
present, while the signal of interest occurs relatively infrequently, and
lasts only about one-half second.  (The background signal is also of a
somewhat smaller amplitude than the signal of interest.) Of course I realize
that anything like this will probably also discriminate against a "legal"
signal of the same frequency, but I can live with that.

I am posting this mostly because I have been simply astounded at the depth
and breadth of the knowledge and experience of this group, as well as the
generousity with which it is shared.  I certainly appreciate the fact that
any little tip could save me an awful lot of time and frustration.

>I am constructing a PIC based system to display speed in MPH as a
>function
>of the Doppler frequency from an X band radar antenna.

>The conversion factor is 31.398 Hz per MPH. I plan to measure the
>period
>over a few cycles and, either by implementing an inverse math
>function, or
>some clever lookup scheme, derive the BCD data for the display.
>Resolution
>needed is 1 MPH.

This seems too obvious, but if you count how many cycles occur in 31.8492
ms (1/31.398), the count will be directly in mph.  Probably you want to
count for a multiple of this period, then divide the result by the number
of periods counted.  This will reduce the +- 1 mph uncertainty that would
otherwise be present.

If you synchronize the start of counting to a cycle of the output, then
the count will jitter less.  At these low frequencies it may also be
practical to use a combined frequency/period measurement.  But for now
just to get something on the display, count for 31.84 ms and display.

To display in BCD, for small numbers (<255), it's practical to use
repeated subtraction of 10, 100, etc.  Or count in BCD in the first
place, though that makes averaging, division, etc. more complicated.

>
>I would appreciate any insights, shortcuts or alternatives to this
>plan, but
>even more so, some ideas on dealing with the following complication:

>   (The background signal is also of a
>somewhat smaller amplitude than the signal of interest.)

That's probably the key to it, if the signal of interest is larger than
the background it will dominate the counting.  It will be very hard to
extract anything useful if the interference is comparable in level and
frequency to the desired signal.

I think that many implementations use an analog PLL to lock on to the
signal of interest, then count with a digital counter.  If the output of
the PLL is changing rapidly, it is likely to be noise and should be
ignored.  (About the simplest way would be to look at the counts and only
display after 2 or 3 close to the same count have occurred)  Once locked,
the PLL could also serve as a tracking filter, though that may not be
practical since the signal is of such short duration.

___________________________________________________________________
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

Your problem is a nice fit for the stuff I was promoting in my post
earlier today: Title "Re: FFT on PIC midrange". If that post
makes any sense to you (I have no idea of your tech. background),
a 'back of the napkin' analysis of your numbers says your
problem is 'just' do-able using another 'poor man's' DSP
technique on a midrange PIC (needs maybe 1 to 2 bytes RAM
per mph. bucket). Anyway, it is an interesting challenge,
and I would help you just to see how it works. So e-mail
me if you want to explore this some more.

R.M.M.

I'm a real amateur on PLLs but some recollection of an
earlier post by someone who seemed knowledgable
suggests that 'locking' a PLL over a 15 to 1 freq. range
for weak signals, in the presense of strong inband interfering
signals, is not in the cards.  Digital techniques have ways
of 'cheating' some of the linear theories and methods, at the
expense of predictability and other good behaviors. But
not every project is rocket science, with the high penalties
on 'occasional' ooopses.

R.M.M.

It seems to me, that the theoretical beast you want,

is a learning program, that learns the characteristics of the Background
noise, and feeds them back as a negative feedback attenuating the
background noise.

Then all you need to do, is use the remaining signal to run your doppler
to bcd conversion program from.

One way of doing this, might take a couple of processors to achieve, but
essentially, would simply involve the user pushing a "Calibrate Button"
in order to "Learn the Environment".

This button, would take the doppler reading of the background noise, as
measured by the doppler converter, and convert it into a numeric value,
which could then be used to generate a doppler signal that was at the same
frequency, and in phase with the background noise.

The "Digitized Signal" would of course be "Cleaner" than the original,
creating feedback and interference patterns, which could likely be
filtered out with a band-pass filter that blocks anything not in the
"Interesting" range.

The second processor, (or second thread on a fast enough base processor)
would simply convert the numeric value back into a signal, which would
probably be fed into the negative bias of an amp to attenuate the signal.

Since the background would be essentially attenuated out of the signal,
the larger interesting signal would be the only signal that would get
measured.

CAVEAT....

This only would work, if the FAN ran at a constant rate....

Old fans tend to surge, which might result in a varying frequency...

In that case you would have to do a second order analysis to get the
surge frequency, so you could damp that with the feedback system.

Anyway, it sounds like an interesting problem.

GREY

GRAEME SMITH                         email: grysmithfreenet.edmonton.ab.ca
YMCA Edmonton

Address has changed with little warning!
(I moved across the hall! :) )

Email will remain constant... at least for now.

In RF, there is something called "capture effect" in which you can tell one
signal over another just by "capturing" the one with higher amplitude and

You mentioned that the background interference signal is of smaller
amplitude than the reference signal, so you may be able to use the capture
effect.

You also mentioned that the reference signal occurs "infrequently" and lasts
about 1/2 sec. Does this mean that it is not periodic? If this is the case,
then the problem is much harder, because you cannot "predict" when the next
signal will occur.

I hope this helps!

Regards,
Andres Tarzia
Technology Consultant, SMART S.A.
e-mail: atarziasmart.com.ar

-----Original Message-----