Order Tray | Contact Us | Home | SIG Lists

[dsp] Analog front end design

scott at opentrac.org scott at opentrac.org
Tue Apr 26 03:40:36 UTC 2005

I'm not actually using a dsPIC - at least, I have no plans to at the moment.
I'm using an AT91SAM7S64, which has an ARM7TDMI core at around 50 MHz.  A
multiply takes 4 cycles and it's got a load-store architecture, so it's not
going to keep up with a 'real' DSP.   I *know* it can be made to do 1200
baud AFSK well in 4 MIPS or less, but unfortunately I don't have access to
the proprietary code that proves it!  Wouldn't mind licensing it if I could.

I think it can be made to do 9600 baud, but I haven't really experimented
with it yet.  There's no 9600 baud activity around here and it's going to
take some effort to get a real-world test environment set up.  I also need
to do more research on GMSK and G3RUH, and look into compatibility with
existing hardware.

I suppose I could just go with a real DSP (I've got around 500 surplus 100
MIPS TI chips on hand) but it'd considerably complicate the design.  I'm
going for simplicity and low part count.  If at all possible, I want
everything running on the SAM7S chip.  It should be feasible to build a
single-port 1200 baud only version of this thing using just a couple of op
amps for filtering and buffering ahead of the on-board 10-bit ADC.  With the
built-in USB controller, it'd be more flexible and cheaper than the Elcom

I'm looking over www.dspguide.com now.  I think that'll keep me busy for a
little bit - thanks!

Speaking of TNC and DSP experts, if you know anyone who'd be willing to
write code for this (either the 1200 baud or 9600 baud portions) cheap, let
me know.  I can't offer a ton of money, but it's an opportunity to
contribute something to the ham community - open source modem code to go
with an open TNC design that'll sell for less than the KPC-3+ and far exceed
it in flexibility.  For that matter, I'd be willing to offer a share of the
profits, but that's a bit more of a risk than cash up front.  =]  I wouldn't
mind being freed from the DSP learning curve to get back to the programming
I know.  There's certainly plenty of that left to be done.


-----Original Message-----
From: David Willmore [mailto:willmore at optonline.net]
Sent: Monday, April 25, 2005 7:37 PM
To: scott at opentrac.org
Cc: willmore at optonline.net; dsp at lists.tapr.org
Subject: Re: [dsp] Analog front end design

> I've been using the dsPIC filter designer lite to design filters so far.
> I'm not designing for a PIC, but the program's not really PIC-specific.
> generates working C code that I can feed real data and then plot the
> in Excel.  I'm still a bit lost when it comes to actually choosing the
> parameters.  I know the passband I want, but I'm not sure where to set the
> stopband, for example.  The ripple parameters I find don't really matter
> I'm constraining it to a limited number of coefficients - I just take the
> best it can give me.  Not always sure what's 'good enough' though.

That is a nice program.  It's more useful for applications where the precise
filter performance is critical.  For some applications, it's just not that
critical.  But, it's still a good tool to show you what the compromises are
between filter types.

For a data filter, you want a nice gentle curve to the filter rolloff,
ripple doesn't matter all that much.

> It does do a good job of showing me the results of my design.  I can at
> least keep tweaking things until it looks like what I want.

Yep, it's great for that.

> I'm not so worried about clock recovery and such in the digital domain.  I
> can handle digital, I've done stuff like that before - decoding data off
> XR2211, for example.  But I'm lacking a lot of the math background I need
> for the DSP portions and it's a steep learning curve.

Start with www.dspguide.com.  Buy the book once you're read through it
and relalize how useful it is. :)  I like it, but wish it wouldn't be
so shy with the math.  Complex numbers don't bother me and the text goes
to extremes to avoid using them.  I find them very elegant tools, but
I'm a little esoteric myself. :)

> Anyway, is what I'm describing with the autocorrelation (?) the same thing
> you're talking about?

Not autocorrelation, but a correlator would make a good data recovery
You *know* what a data transition will look like, so correlate the data with
one and see what the output looks like.  With the CPU ability of a dsPIC,
you shouldn't have any trouble with that.

Come to think of it, the output of an autocorrelator could be fed into a
correlator and the first (lowest frequency) peak could be used as the data
rate.  That won't give you phase, but it'll give you frequency.  I just
there must be better and less CPU/memory intensive ways.

With the amount of CPU available in a dsPIC, one should be albe to make a
completely kick ass (pardon the term) 1200 baud modem.  Even a good 9600
baud one.  Next time I get a chance to bug Bob (Robert McGuire) about this,
I'll see what tricks he had to use to fit this into the early DSP TNCs.


More information about the dsp mailing list