[Elecraft] SDR-IF and I/Q questions

[Larry Phipps]

Take a look at TRX-Pan, Tony. It does exactly that, is very well 
integrated with the K3, properly displays both main and sub passbands in 
all modes (including data sub-modes) and has a very nice uncluttered 
interface. It is very small code-wise, launches immediately and runs 
well even on netbooks. It is also very simple to install. It requires 
either LP-Bridge or TRX-Manager as the serial interface, but most SDR 
users would need LP-Bridge anyway. LP-Bridge is also small and normally 
runs in the background.

http://www.telepostinc.com/TRXP.html

Larry N8LP



On 11/10/2011 10:27 AM, elecraft-request at mailman.qth.net wrote:
> Message: 26
> Date: Wed, 9 Nov 2011 21:07:38 -0600
> From: Tony Estep<esteptony at gmail.com>
> Subject: Re: [Elecraft] SDR-IF and I/Q questions
> To:elecraft at mailman.qth.net
> Message-ID:
> 	<CACHwrmPUciYL54oJ+sim8r+xjuaqOt9=1gcY3caMkN5V74ccMw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Nov 9, 2011 at 5:51 PM, Don Wilhelm<w3fpr at embarqmail.com>  wrote:
> ==========
> Somewhere along the line there may be a third kind of SDR software:
> program that displays a nice panadapter and provides solid CAT control for
> 2 VFOs, but nothing else. In other words, the routines devoted to signal
> processing, filtering, etc. would be left out, and those functions would be
> left to specialized computing functionality inside the radio, as is done
> with the KX3. It will be cool if the arrival of the KX3 provides the
> motivation for some brave soul (or group) to gut-rehab one of the
> open-source programs such as PSDR so that it fits this description.
>
> Benefits would include a much reduced CPU load and elimination of latency
> problems. The most important benefit, however, would be that cutting out
> the massive code bloat might make it possible for somebody to actually get
> a handle on the mysterious interdependencies and internal conflicts inside
> the code that cause bugs: disappearing config files, unexplained shutdowns,
> loss of functionality, etc. The traditional excuse for these phenomena is
> to blame the OS, the computer, or the user, but we all know better. The
> reality is that when you have a huge, open-ended project, with rubbery
> design specs, with many hands contributing independently, partly
> object-oriented and partly not, partly written in native code and partly in
> interpreted code, partly tested and partly not, you are going to have
> problems. A smaller piece of code with clear design objectives, unity of
> purpose, unity of design and coding standards, and clearly enunciated
> testing checkpoints, would be a really cool thing for the next generation
> of the ham station hardware/software combo.
>
> 73, Tony KT0NY