[dsp] AFSK demodulator code for ARM7TDMI?

[scott at opentrac.org]

Right, and I think there was some low-pass filtering needed too.

Haven't learned much about the fast interrupt features yet - guess I'll have
to look into that some more.

Scott

-----Original Message-----
From: dsp-bounces at lists.tapr.org [mailto:dsp-bounces at lists.tapr.org]On
Behalf Of John B. Stephensen
Sent: Friday, February 11, 2005 4:42 PM
To: TAPR DSP Mailing List
Subject: Re: [dsp] AFSK demodulator code for ARM7TDMI?


I haven't implemented FSK demodulation yet, but an FFT should be
unnecessary. If you have in-phase (I) and quadrature (Q) samples, the
algorithm:

I[1] * (Q[1] - Q[0]) - Q[1] * (I[1] - I[0])
-------------------------------------------
              I[1] * I[1] + Q[1] * Q[1]

where [1] is the current sample and [0] is the previous sample is supposed
to implement a frequency discriminator. It's no good for audio as there is
lots of distortion, but it should be good for data. I'm working on 100 kbps
to 4 Mbps data links so the filtering and demodulation is done in an FPGA
and the ARM MCU is used for Reed-Solomon encoding and decoding. For lower
speeds the ARM7 should be able to do it all.

The portable RTOS's are usually written in C and the efficiency depends on
the compiler used. They usually run in user mode and don't make use of
system and other modes for task switching and error recovery. I wrote a very
simple non-preemtive OS in ARM assembly language that does a task switch in
less than a microsecond.

If the PDC can handle the CODEC it will mean a lot less overhead. Another
approach is to use the fast interrupt and the dedicated registers associated
with it.

73,

John
KD6OZH

----- Original Message -----
From: "Scott Miller" <scott at opentrac.org>
To: "TAPR DSP Mailing List" <dsp at lists.tapr.org>
Sent: Friday, February 11, 2005 22:16 UTC
Subject: Re: [dsp] AFSK demodulator code for ARM7TDMI?


> > If you purchase the ARM developers guide there are examples of FIR
filters
> > and a radix-4 FFT implementation. The speed is adequate for any
> application
> > processing data from an audio CODEC.
>
> Thanks, I'll have to look into that.  That brings up another question...
> what's best for decoding AFSK - Goertzel algorithm, FFT, quadrature
> demodulator, etc?  From the description I read, the Goertzel algorithm
> sounded less CPU-intensive than a regular FFT for a small number of
> frequencies, but I think it might take too long a sample period to be very
> useful.  The quadrature demodulator I'm still learning about - seems like
it
> needs a certain amount of low-pass filtering.  I understand some of the
> basic concepts, but the reality of their implementation is another matter.
>
> > Since I couldn't find a fast real-time OS for the ARM7, I ended up
writing
> > one. If anyone wants a copy for amateur radio applications, send me an
> > email.
>
> Define 'fast'.  I'm using FreeRTOS.  Works so far, but then I'm not doing
> any signal processing yet!  I'm hoping that the peripheral data controller
> functions will help keep my interrupt processing overhead low - if I can
> load sizeable blocks of data from the codec without an interrupt each
byte,
> it'll mean a lot less interrupts.
>
> Scott
> N1VG
>
>
> _______________________________________________
> dsp mailing list
> dsp at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/dsp
>



_______________________________________________
dsp mailing list
dsp at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/dsp