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-requ...@mailman.qth.net wrote: > Message: 26 > Date: Wed, 9 Nov 2011 21:07:38 -0600 > From: Tony Estep<estept...@gmail.com> > Subject: Re: [Elecraft] SDR-IF and I/Q questions > To:elecraft@mailman.qth.net > Message-ID: > <CACHwrmPUciYL54oJ+sim8r+xjuaqOt9=1gcy3camkn5v74c...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Nov 9, 2011 at 5:51 PM, Don Wilhelm<w3...@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 ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
