I'm interested in building a FSK modem around a PIC microcontroller,
and am wondering how most FSK receivers convert the frequency to bits.
I'm open to a unique solution, and I've seen some frequency to voltage
converters that may work, but would like to know what some current
techniques are that may be a lot more reliable and simpler.
Thanks in advance!
Dave

wrote in message
oups.com...
I'm interested in building a FSK modem around a PIC microcontroller,
and am wondering how most FSK receivers convert the frequency to bits.

The cheap and sleazy route is what you see many people doing on PICs (and
similar) for DTMF detection: To detect a frequency F1, using your ADC's
digital output, multiply the digital word by sin(F1*t) and cos(F1*t).
Square and add the result, so that you have
(ADC_Out*sin(F1*t))^2+(ADC_Out*cos(F1*t))^2. Take the running average of
what you get, and use a threshold detector to decide whether or not that
frequency is prsent.

The 'cheap and sleazy' part of this comes in as follows:

1) Arrange the frequencies to be, e.g., F1 and F2=2*F1. Sample at 8*F1.
Now, all the sine and cosines become +/-1 -- no multiplier needed.
2) Use 'abs' rather than squaring the results -- no multiplier needed.

This isn't particularly robust (it fails rapidly if the input frequencies
are off -- the DTMF guys typically don't have to worry about this because
DTMF generation is very well controlled), but it gets the job done when you
have a relatively high SNR signal and it's very simple and fast to implement
since you've gotten rid of the multiplications.

For more narrowly spaced FSK detection, this still works, although you start
having to build up tables of sin/cosine values -- and perform the
multiplication. If you do have a hardware multiplier around in your
particular PIC, this is perhaps still the way to go. If not, you start
looking at what resources you do have... you can design more 'proper'
digital filters with coefficients of only +/-1 and zero, although sometimes
the implementation ends up being more CPU intensive than just doing software
multiplies.

Using a tool such as Matlab is very handy for trying our various
filtering/detectoin techniques prior to having to sit down and code up the
result in C or assembly for a system running in real time!

---Joel Kolstad

Joel Kolstad wrote:

wrote in message
oups.com...

I'm interested in building a FSK modem around a PIC microcontroller,
and am wondering how most FSK receivers convert the frequency to bits.


The cheap and sleazy route is what you see many people doing on PICs (and
similar) for DTMF detection: To detect a frequency F1, using your ADC's
digital output, multiply the digital word by sin(F1*t) and cos(F1*t).
Square and add the result, so that you have
(ADC_Out*sin(F1*t))^2+(ADC_Out*cos(F1*t))^2. Take the running average of
what you get, and use a threshold detector to decide whether or not that
frequency is prsent.

The 'cheap and sleazy' part of this comes in as follows:

1) Arrange the frequencies to be, e.g., F1 and F2=2*F1. Sample at 8*F1.
Now, all the sine and cosines become +/-1 -- no multiplier needed.
2) Use 'abs' rather than squaring the results -- no multiplier needed.

This isn't particularly robust (it fails rapidly if the input frequencies
are off -- the DTMF guys typically don't have to worry about this because
DTMF generation is very well controlled), but it gets the job done when you
have a relatively high SNR signal and it's very simple and fast to implement
since you've gotten rid of the multiplications.

For more narrowly spaced FSK detection, this still works, although you start
having to build up tables of sin/cosine values -- and perform the
multiplication. If you do have a hardware multiplier around in your
particular PIC, this is perhaps still the way to go. If not, you start
looking at what resources you do have... you can design more 'proper'
digital filters with coefficients of only +/-1 and zero, although sometimes
the implementation ends up being more CPU intensive than just doing software
multiplies.

Using a tool such as Matlab is very handy for trying our various
filtering/detectoin techniques prior to having to sit down and code up the
result in C or assembly for a system running in real time!

---Joel Kolstad


You could also do this by coding up the digital filters using only
shifts. This is not for the faint of heart if you haven't done DSP
before, but it can be done and should get you fairly good results. I'd
recommend prototyping the algorithm on a PC then making sure that you
have enough horsepower in your target processor before you start
building a board.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Sun, 16 Jan 2005 15:36:09 -0800, Tim Wescott
wrote:

You could also do this by coding up the digital filters using only
shifts. This is not for the faint of heart if you haven't done DSP
before, but it can be done and should get you fairly good results.

With FIR filters and 100-200 bytes of RAM, the shifting needs to be
done only once when the sample arrives, by saving each intermediate
value after each shift into a table. When the next sample arrives, the
old sample table (instead of the original sample value only) is
shifted into the next position (tap) of the FIR. This shifting can be
done either by block copying or pointer arithmetics.

Since all taps in the FIR have access to all shifted versions of the
corresponding sample, all that needs to be done, is adding together
those values selected by the coefficient multiplier.

If the tap multipliers are constant and there are sufficiently ROM to
have a separate routine for each tap, the elements selected are known
at compile time, so you do not have to shift and test the multiplier.
Assuming the original sample value is in Shifted[0] and the left
shifted values in Shifted[1..7] and the sample value needs to be
multiplied e.g. by 19 (00010011) the multiply by 19 routine would be
similar to

Mul_19:

Add Shifted[0]
Add Shifted[1]
Add Shifted[4]
return

Thus,even if the processor lacks the multiply instruction, you only
need to make on average 4 additions (for 8 bit multipliers) at each
tap. However, the additions must be 16 bit wide for 8 bit samples and
coefficients.

Paul OH3LWR