[hpsdr] Odyssey dsPIC33 RAM usage

[Murray Lang]

Many thanks Frank.

Hilbert looks like the way to go. It's more likely to succeed for me 
than using a box cutter and a soldering iron. It also has the benefit of 
making the project easily reproducible. It can be cut if the code is 
moved to a system with a stereo codec.

The AGC problems you refer to remind me of a posting way back by Phil H. 
regarding Epimetheus. It was suggested (by myself and others) that it 
include A/D inputs, potentially for things like ALC. This seemed to stir 
up repressed anxieties in Phil resulting from bitter experience.

While I've got you, could you please give me a 1 to 3 sentence 
description of how the Odyssey SDR software hangs together. Something 
like "the codec interrupt handler simply dumps the samples into a queue, 
with all of the SDR code running in a loop in the main line" or 
whatever. Maybe you use a 3rd party multitasking kernel (which can both 
simplify and complicate things).

I like the idea of a cooperative multitasking kernel for this 
application. Since the system as a whole requires each of its parts to 
complete, there's no point in preempting one task with another (other 
than I/O interrupts of course) because this just adds overhead. 
Obviously this requires that the tasks be written in a certain way, but 
preemptive multitasking imposes its own discipline as well. Since my 
programming experience is almost entirely with big fat OSs, I'd 
appreciate comments from anyone who's used a distinct cooperative 
multitasking kernel, home brewed or otherwise, for a DSP application.

Cheers,
Murray VK6HL

Frank Brickle wrote:
>
>
> On Sun, Jun 1, 2008 at 11:08 PM, Murray Lang <murray.lang at bbnet.com.au 
> <mailto: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 


 1212464902.0