[hpsdr] Odyssey dsPIC33 RAM usage

[Murray Lang]

Hi Frank,

As Lyle has pointed out, my board only has a mono codec, so I'm going to 
have to splice in a stereo codec or get hold of a good Odyssey PCB 
layout and get a prototype etched. Assuming this, I can now further 
advertise my ignorance.

I figured that since I'm only planning to use narrow band voice modes, 
I'd only need to sample at, say, 8KHz. Of course this means that if I 
want band coverage I'll need to sample at IF, and select the RF 
frequency elsewhere. I gather this somewhat relates to your stipulation 
that data arrives at baseband, eliminating the need for DDC. Am I 
interpreting you correctly there? To get a panoramic display of the band 
segment I could increase the sample rate back up, but cut the number of 
FFT points down to 64 and possibly reduce the bit resolution to the minimum.

Regarding the fixed point limitation, I guess there's no harm in trial 
and error. Maybe the limited dynamic range of voice modes helps(?)

Regarding AGC, is the problem more that you are implementing a 
transponder? All I'll be aiming for is good old half duplex.

Was the decision to use the dsPIC33 based purely on power consumption? 
It sounds like a more conventional DSP would save a lot of grief.

Many thanks Frank,

Murray VK6HL

Frank Brickle wrote:
> On Sun, Jun 1, 2008 at 10:07 AM, Murray Lang <murray.lang at bbnet.com.au 
> <mailto:murray.lang at bbnet.com.au>> wrote:
>  
>
>     Is the prototype code available? I haven't found any SVN links,
>     but can understand why it would be under wraps given that it's
>     probably quite fluid. Is it based on DttSP? Are the free versions
>     of the Microchip tools likely to be sufficient? Are you using an
>     operating kernel or is it just basically interrupt driven?
>
>
> The SDX code is moving forward fast now.
>
> The free Microchip tools are OK for learning, but you really need the 
> optimizing compiler which is not free.
>
> There are a few fundamental problems using the dsPIC33 for SDR. The 
> biggest one is that it's not fast enough to sustain 256-point complex 
> FFTs at 48kHz. For Suitsat 2 we're using a by-hook-or-by-crook 
> approach in place of the general algorithm exemplified by DttSP. 
> Basically the idea is to stipulate that incoming data arrive at the 
> dsPIC at baseband, so the I and Q arms can be filtered separately with 
> simpler low-pass filters. The processed signal is then mixed to one of 
> a select set of channel bandcenters. The bandcenters are the ones 
> which correspond to "simple" values of the (cos, sin) mixing LO.
>
> Another big issue impacting generality is filter scaling. Since 
> internal data is fixed point, you have to juggle the coefficients to 
> make best use of the 16 bits available for the filter coefficients and 
> gain. There is no direct path from a filter spec to a design. You have 
> to experiment using a combination of science, art, and cunning.
>
> Along the same lines, the other big snag is AGC. We're using very 
> elementary power computations on the input signals to determine binary 
> shifts on the output.
>
> None of this means that the dsPIC33 is unsuitable for SDR 
> applications. It's not a general-purpose engine, though. You need to 
> look carefully at your application and figure out where you can cut 
> corners.
>
> 73
> Frank
> AB2KT
>
>
>
>     Cheers,
>     Murray VK6HL
>     _______________________________________________
>     HPSDR Discussion List
>     To post msg: hpsdr at hpsdr.org <mailto:hpsdr at hpsdr.org>
>     Subscription help: http://lists.hpsdr.org/listinfo.cgi/hpsdr-hpsdr.org
>     HPSDR web page: http://hpsdr.org
>     Archives: http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/
>
>
>
>
> -- 
> The only thing we have to fear is whatever comes along next. -- Austin 
> Cline 


 1212376091.0