And after:
29 November 2012
Advanced tuning for UHD in gqrx
Before (well, I cheated and took this picture after the other):
And after:
The patch supporting UHD advanced tuning is in git for gr-osmosdr now.
And after:
28 November 2012
L-Band satellite signals on 1544.5MHz
I've received what I think may well be signals from some SARSAT satellites on 1544.5MHz over the last few hours. I wasn't expecting the one in the screen shots, so its not from any of the birds I'm tracking with gpredict.
24 November 2012
4 November 2012
RXAMADRM but no pics yet.
I heard some DRM activity on 40m this morning and decided to give RXAMADRM a whiz. I got it working with my Signalink-USB attached to my KX3. In order to see signals at all in the waterfall display, I needed to crank the KX3's audio level up to 40 (max) and set the Rx audio level on the Signalink to max too.
RXAMADRM was able to decode fair bit of data over an hour or so, but never enough to print images. I really need a decent antenna for HF. And less noise.
RXAMADRM was able to decode fair bit of data over an hour or so, but never enough to print images. I really need a decent antenna for HF. And less noise.
3 November 2012
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.
I found that I had to build the package with:
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.cI also bumped the package version so that it wouldn't get replaced by the update manager.
+++ 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 found that I had to build the package with:
dpkg-buildpackage -b
1 November 2012
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.
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:
message. I located a good spot for a bit of bodgery and tripled the inter-character timeout that was being exceded:
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.
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-1.2.15.1.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:
+++ 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;
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.
Subscribe to:
Posts (Atom)