* On 2010 08 Dec 07:49 -0600, Chris Bryant wrote:
> On Tue, 2010-12-07 at 20:33 -0600, Nate Bargmann wrote:
>
> > Thanks Chris.
> I trust it all made some sense.
>
> Looking beyond the current test results, a couple of thoughts occur to
> me:
>
> - Could I enter a plea to put the K2 in extended command mode as there's
> a whole lot more info available?
I intend to do that in the backend to get the needed information. I
also plan to read the initial value and restore it upon the rig_close
function.
> - Following on from that, there's some useful K2-specific info that
> becomes available that the command set of rigctl doesn't support. It's
> clearly unreasonable to expect hamlib to support rig-specific data and
> functions which aren't common to a large set of rigs. So I'm wondering
> if there's a way of accessing raw data, eg the serial command strings
> through hamlib, or indeed if this is desirable within hamlib's
> architecture. Here's an example:
>
> In extended mode, I can drive the K2 by simulating front panel button
> presses with the SW command. Useing cutecom terminal emulator, with half
> a dozen SW, I can access the filter setup menu and read back the BFO
> frequencies, which change with filter settings and rig mode. I need
> these frequencies so I can compensate the display in quisk which will be
> connected via a Softrock SDR to the K2's IF.
>
> Perhaps that wasn't such a good example, as I could arrange quisk to
> connect directly to the K2's serial port, get these values as a one-off
> operation, close the port, then open a K2 connection again via hamlib
> for normal operation. But the idea is valid, there may be other
> unsupported info I'd like/settings I'd like to change while hamlib is in
> charge of the serial port.
Actually, it is a good example. In rigctl check out the 'w' command
which is intended to send a raw string. We can also expose that through
rigctld. I have, in fact, used the SW command in a K3 macro that is
then accessible from one of its front panel buttons. That is outside
the scope of Hamlib, but I am familiar with the functionality.
> > I'll set to work on getting the mode and filters working. Once I get
> > that committed to SVN I'll post back. The nice thing is that I should
> > be able to test this using the K3 so hopefully all you'll need to do is
> > verify that it works on the K2.
> Sounds good - you get all the hard work ;-) I'll have a think about the
> split functions and see if I can improve my understanding
No problem. I'm not fast, but I think this should not be incredibly
difficult. I hope we can get all of this into the next release of
Hamlib.
73, de Nate >>
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://n0nb.us/index.html
|