qtrfiq

I've just added qtrfiq to github.  It is a simple gnuradio-companion flowgraph that provides a QT fosphor display fed from an audio IQ input (such as that from the Elecraft KX3 transceiver) that determines the radio's frequency by using hamlib's rigctl.

Approaching digital mode nirvana

Today I found myself running two instances of fldigi alongside WSPR and WSJT, all happily using the same SignalinkUSB soundcard interface to my KX3 and sharing access to the rig via Hamlib's rigctld.  Well, all but WSJT which doesn't have hamlib support in this build.

More buttons in gr-kx3.

A little progress in gr-kx3.  Still bugs though.

A better bodge for Hamlib and the KX3

I bit the bullet and dist-upgraded to Ubuntu 12.10.  In doing so the previous hamlib package bodge for increased timeouts with the KX3 was discarded as the hamlib package from the repos upgraded.

I figured that a more elegant bodge was probably acheivable having proven the nature of the fix.  I discovered that I could localise the change to the Elecraft backend.  This is the change that I made.

--- hamlib-1.2.15.2.orig/kenwood/k3.c
+++ hamlib-1.2.15.2/kenwood/k3.c
@@ -108,7 +108,7 @@ const struct rig_caps k3_caps = {
     .serial_handshake =    RIG_HANDSHAKE_NONE,
     .write_delay =        0,    /* Timing between bytes */
     .post_write_delay =    100,    /* Timing between command strings */
-    .timeout =        600,    /* FA and FB make take up to 500 ms on band change */
+    .timeout =        3*600,    /* FA and FB make take up to 500 ms on band change */
     .retry =        3,

     .has_get_func =        K3_FUNC_ALL,

I also bumped the package version so that it wouldn't get replaced by the update manager.

I found that I had to build the package with:

 dpkg-buildpackage -b

Using hamlib's rigctld with the KX3 and fldigi

I've been slowly solving some issues that I've noticed over the past few weeks.  Previously, I'd commented on audio glitches affecting tx and rx audio with fldigi and WSPR using my Signalink-USB to interface with my KX3.

I eventually discovered that the problem went away when I bypassed the USB hub and connected the SignalinkUSB directly to my laptop, so that's how I've been operating it for the last week or so, and all seems much better.  What bothers me is that I can't imagine the USB2.0 feed to/from the hub would be saturated by a pair of 48kHz soundcards and a pair of USB/RS-232 adapters.  We're only talking about a few megabits per second for that lot, out of a best case arguably unreachable theoretical maximum of 480 megabits per second.

I realised a while ago that the USRP B100 warranted a seperate point-to-point USB connection if I wanted to operate it with its maximum  sample rates.  Having 3 USB connections just to interface my laptop to radio gear is getting a bit much.  I wonder if the el cheapo hub from PC World is to blame.  Perhaps I'd better borrow another and see if the situation improves.  I haven't even considered adding the (now superseded) Funcube Dongle Pro to the pile of connected peripherals recently, but a crappy hub might explain the frequent overflow indications that I used to get with it.

Anyway, the next thing on the list was to get righteous with a many-to-one CAT control setup for the KX3, courtesy of hamlib's new(ish) rigctld.  It goes without saying that my half-assed panadapter script that displays the I/Q output of the KX3  should be able to run  simultaneously with fldigi and/or wspr with all of them having the ability to read whatever info they need from the rig and equally have the ability to send commands back to it.  In the old days, it would have been done with rpc.rigd but rigctld seems to be more in vogue these days so I thought I'd give it a whizz.

$ rigctld -m 229 -r /dev/ttyUSB1 -s 38400 -v
Opened rig model 229, 'K3/KX3'

Next, to set up fldigi to use rigctld instead of talking directly to the KX3.  Now I started off with what I thought were very conservative settings for the intervals and delays, based on the premise that I'd have two applications with multiplexed connections through a TCP socket server proxy hooked up through a 38.4 kilobits per second bottleneck.  That made fldigi very sluggish and prone to pausing whenever I used its GUI to fiddle with the rig frequency.  I ended up reversing my approach and going for short delays and intervals and this proved much more effective and provides a fluid response and rapid QSYing when required. The screenshot below shows the figures I settled on. I kept the retry interval fairly conservative so as to stand a better chance of recovery in the event of congestion on the serial bottleneck.

I then discovered that when changing bands on the KX3, rigctld detected a 600ms inter-character timeout on any ongoing serial transaction with the KX3, and initiated a retransmission.  This caused a mis-synchronisation between commands and responses between rigctld and the KX3 for a while before the knickers got unknotted and command/response pairs became sane again.  Infortuntaely by this time, fldigi had given up and started to sulk, presenting an invariant value of 2700 as a centre frequency.

I don't know if the KX3 is expected to pause serial communications during band changes. I'd like to think that its a bug that will be fixed, but I wasn't prepared to wait for that to happen.  I'd also expect fldigi to try a little harder to re-establish CAT control, which it could have done once rigctld had got out of its rut.

However it seemed to me that hamlib needed hacking to fix this, so I pulled down the source package for hamlib with:

apt-get source hamlib

Then I fetched its build dependencies with

sudo apt-get build-dep hamlib

then had a rummage around in the source looking for the origin of the timeout error
message.  I located a good spot for a bit of bodgery and tripled the inter-character timeout that was being exceded:

--- hamlib-1.2.15.1.orig/src/iofunc.c
+++ hamlib-1.2.15.1/src/iofunc.c
@@ -491,8 +491,8 @@ int HAMLIB_API read_string(hamlib_port_t
    * Wait up to timeout ms.
    */
   //DML hack multiplied timeout
-  tv_timeout.tv_sec = (2*p->timeout)/1000;
-  tv_timeout.tv_usec = ((2*p->timeout)%1000)*1000;
+  tv_timeout.tv_sec = (3*p->timeout)/1000;
+  tv_timeout.tv_usec = ((3*p->timeout)%1000)*1000;

As you can see from the patch listing above, I'd already tried doubling it, with no improvement.  Next, to build the package, I ran:

dpkg-buildpackage

 in the hamlib directory.  I was prompted to jump through some patch control hoops that I wasn't expecting, but can't say I disapprove of, then reran the command and waited for the build to complete.  Next was the installation of my brand new deb packages (again).

sudo dpkg -i ../*.deb

This time, when I cycled around the band, rigctld seemed happy to wait longer for outstanding transactions.  However, flidigi now needed a little tweak to the retry interval so that it exceeded the newly tripled  timeout in hamlib. I cranked it up to 2500 milliseconds, so it exceded the 3*600 millisecond timeout in the hamlib call.

To be honest, I doubt that my hack is in any way ideal; there's probably a better place to make changes that are specific to the KX3 backend, and I'll probably look into that shortly, but for now it's all working nicely.

Gnuradio, hamlib and the KX3

Having got my hands on a stereo line isolator which has resolved the ground loop issues I had when connecting the I/Q (via a Griffin iMic) and USB/RS-2232 for CAT control simultaneously, I decided that I needed a proper panadapter facility for my KX3.

I started off by trying to handle CAT via Hamlib's rigctl using pexpect.run() to invoke rigctl directly in the gnuradio-companion flowgraph.

After struggling for a bit, I resorted to hacking the generated python directly.  It works nicely for me now.  The Waterfall display scale follows the KX3's dial frequency as I knobulate the VFO and I can click in the waterfall to re-tune the radio.

The main issue left to resolve is to determine the effect of PBT and/or RX SHIFT on the waterfall display's centre frequency.  This is apparently supported by hamlib's K(X)3 backend and can be accessed

Rig command: l ifctr
Level: Level Value: 8210000.000000

However, rigctl always seems to return the same (default) value, that is  8210000.0 plus the IF offset, which is always apparently 0, irrespective of PBT or IF SHIFT settings.

Checking the use of the FI/FInnnn command/response by talking directly to the KX3 over the serial port yields similar results:

 FI;FI0000;

 So, there is presumably a bug/omission in the KX3 that causes the FI response to always be 0.

Nevertheless, I'm happy to have a panadapter for the KX3 that allows me to click-to-tune.  It's come in handy with the amount of contest traffic on the HF bands this weekend.

Next plan is to add a software defined sub-receiver, so I can listen to more than one thing at once!

I've been asked what stereo line isolator I used.  I used one of these.  I would have used one of these instead, had I found them before ordering the other one.  I'll probably get one anyway, for the convenience of fewer cables.

Update: the Python code for this is here.