[hpsdr] Odyssey dsPIC33 RAM usage

[Frank Brickle]

On Sun, Jun 1, 2008 at 11:08 PM, Murray Lang <murray.lang at bbnet.com.au>
wrote:


> 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 could be *way* wrong about this, but can't you replace the chip itself on
the board so as to get stereo? That would get you more onboard memory as
well.

Anyway, given your design decisions below, you aren't really up against
serious bandwidth limitations, so you can certainly cheat a bit, give away
half the bandwidth, and re-create the I/Q signal from I or Q alone inside
the dsPIC. For the application you're describing one of the simpler IIR
Hilbert transformers might work just fine on the real or imaginary (mono)
part only. What you get is not the Q part from the I part, but rather a new
I/Q pair that's out of phase with the input, but with the proper phase
relationship between the arms themselves inside the band of interest.

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?


Exactly.


> 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.


Just for the panoramic display, you don't need to compute and display every
buffer, nor the complex spectrum either. There might be a little
multitasking devilry required even for this, but not much. You'd probably
want to break up the FFT computation so as to simply discard the buffers
you're ignoring.

Another possibility is to compute a fairly coarse panoramic spectrum using
the Goertzel algorithm and adaptively or selectively refine sub-bands of the
spectrum on a finer Goertzel grid. This technique has the advantage of being
arbitrarily interruptible, and it doesn't waste cycles on patches of the
spectrum where nothing interesting is happening at the moment.

No matter what you do it's going to beat the tar out of my IC-746 bandscope.


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


That it does, tremendously.


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


Same logic applies, only more so. If you have anything like dynamic gain
control outside the device you've eliminated most of  the problem. As an
aside, if you can get away with mono ADC and reconstruct the quadrature
signal inside the DSP, you've banished potential I/Q imbalance problems,
which are themselves one of the class of pests the AGC needs to tame.


> 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.


Power consumption, simplicity, cost. The Odyssey/Siren design is
breathtakingly straightforward, with the QSD/QSE and separate TI CODEC on
the board. Here's evidence: the design is sufficiently simple that even *I*
can help debugging the hardware, and that is setting the bar awfully low,
you can be very sure.

If you're moving ahead with this, please don't be shy with your developments
and roadblocks. I happen to feel very strongly that the low-end projects
(hardware-wise) will prove to be every bit as important as the High
Performance ones, as far as innovative applications are concerned. The
SoftRock is proof enough to convince anyone.

73
Frank
AB2KT


-- 
The only thing we have to fear is whatever comes along next. -- Austin Cline
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20080602/822a378f/attachment-0003.htm>