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 -vNext, 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.
Opened rig model 229, 'K3/KX3'
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 hamlibThen I fetched its build dependencies with
sudo apt-get build-dep hamlibthen 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-184.108.40.206.orig/src/iofunc.cAs you can see from the patch listing above, I'd already tried doubling it, with no improvement. Next, to build the package, I ran:
@@ -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;
dpkg-buildpackagein 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 ../*.debThis 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.
A better bodge for hamlib is described here: http://www.g0hww.net/2012/11/a-better-bodge-for-hamlib-and-kx3.html
Post a Comment