<br><br><div class="gmail_quote">On Sun, Jun 1, 2008 at 11:08 PM, Murray Lang <<a href="mailto:murray.lang@bbnet.com.au">murray.lang@bbnet.com.au</a>> wrote:<br><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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.</blockquote>
<div><br>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.<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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?</blockquote>
<div><br>Exactly.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.</blockquote>
<div><br>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.<br>
<br>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.<br>
<br>No matter what you do it's going to beat the tar out of my IC-746 bandscope.<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Regarding the fixed point limitation, I guess there's no harm in trial and error. Maybe the limited dynamic range of voice modes helps(?)</blockquote><div><br>That it does, tremendously. <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Regarding AGC, is the problem more that you are implementing a transponder? All I'll be aiming for is good old half duplex.</blockquote><div><br>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.</blockquote><div><br>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. <br>
</div><div> </div>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.<br>
<br>73<br>Frank<br>AB2KT<br></div><br clear="all"><br>-- <br>The only thing we have to fear is whatever comes along next. -- Austin Cline