Rx antenna switching with the KX3, Wellbrook Loop and a modified MFJ-1707

My new Wellbrook ALA1530PE receiving loop has been performing very nicely, feeding my KX3 and FCD-Pro+ though a combiner, but so far I have been carefully avoiding any transmitting in order to avoid destroying the loop amp and SDR dongle.

I procured an MFJ-1707 thinking that this might be a reasonable solution, as it is mentioned in the RadCom article on the Wellbrook loop.

I decided to try it out with a dummy load connected as the receiving aerial, and my wire antenna as the transmitting aerial and see what happened.

With power not applied to the 1707, the KX3 was hearing through the wire antenna, as expected.  With power applied to the 1707, the rig went deaf, using the dummy load for an antenna.  So far so good.  My plan was to use the KX3's keyline output as a control line to the 1707.

I had also purchased an Elecraft KX3-PCKT cable set for the KX3, so I had the ACC2 module which allowed me to use a mono phono cable to hook up the KX3's keyline output to the 1707 directly.

However, when I connected it to the powered 1707, the relay in the 1707 de-energised immediately, switching back to the transmit antenna despite the fact that the KX3 was not transmitting.  I puzzled over this for a bit, and then got out my DVM.  Sure enough, the centre of the phono socket on the ACC2 module measured 0V with respect to the 13.8VDC supply line whether the KX3 was transmitting or not.  This had me confused.

I started to wonder about writing to the Elecraft list to ask about this, but then I began to fiddle with the ACC2 IO setting in the menu.  I wondered if I could set up a physical transmitter inhibit interlock.  I quickly bodged together a 3.5 mm mono jack plug wired as a short and confirmed that it would enable the transmitter inhibit function.  I went back to check the status of the Keyline output of the KX3 with the transmitter inhibit enabled, and was surprised to note that it seemed to be operating normally now, pulling down to 0V when the KX3 attempted to transmit and back to floating with the KX3 in receive mode.  More interestingly it now did this whether the transmitter inhibit was active or not.

Swiftly forgetting about the anomaly with the formerly always asserted keyline output of the KX3 I wondered about the prospect of a closed-loop solution, using the auxiliary contact closure output on the 1707 to manipulate the KX3's Tx inhibit line via the ACC2 IO.

With the MFJ-1707 un-powered, the Tx antenna is selected and the Aux output is left floating.  When the 1707 is powered, the relay selects the Rx antenna and grounds the Aux output.  When the keyline control from the KX3 asserts, the relay switches back to the Tx antenna and lets the Aux output float.

By connecting the Aux output to the KX3 and configuring the ACC2 IO menu option to "LO = Inh", the KX3's trnamsitter is inhibited whenever the receive antenna is active and the trasnmitter becomes dis-inhibited when the transmit antenna is selected.

On the face of it, this looked like a great solution, but something troubled me.  I realised that if the ACC2 stereo 3.5mm plug was pulled out of the KX3, the keyline wouldn't switch the 1707's relay and the ACC2 IO input would float hi,, dis-inhibiting the transmitter and probably blowing up the Wellbrook loop's amp during transmission.

I didn't like that at all.  The stereo 2.5mm plug for the I/Q output on the KX3 had come adrift enough times during rats-nest manipulation to make me consider the alternative solutions.

I mulled over the notion of bodging in an open collector stage between the aux contact on the relay and it's phono socket, as it would invert the aux-output logic for the Tx inhibit function and it seemed safer than the other alternative I'd imagined which involved strapping the other side of the aux contact to 12V instead of 0V.

A 2N2222A was handy.  It's emitter was strapped to ground and the base pulled up to 12V with a 10k resistor. The base was also connected to the pad where the aux phono plug's centre had previously been connected.  The aux phono plug's centre was now connected to the collector of the transistor.

It looked like this:

Now with the KX3's ACC2 IO set to "HI = Inh", whenever the KX3's keyline out asserts, the 1707's relay switches to the Tx antenna,  Aux output pulls the ACC2 IO input down and the KX3's transmitter is dis-inhibited.  If the ACC2 stereo plug falls out of the KX3, or the keyline and/or Aux/Tx-Inhibit cables become disconnected at either end, or their conductors fail, the KX3's transmitter remains inhibited.  I liked this.

The only unexpected result of the mod was that without power applied to the 1707, the KX3's transmitter was dis-inhibited.  I hadn't expected this, but I suppose there's enough leakage to pull down the  ACC2 GPIO line.  I like this also.  Without power applied to the 1707, the transmit antenna was selected so there was no need for the KX3's transmitter to be inhibited.

I've tested it thoroughly with a dummy load in place of the Wellbrook loop, and it seems good.  I'm pretty happy with this solution.

Now, the biggest risk seems to be the idiot wearing the headphones.  If I somehow modify the ACC2 IO menu option, I could blow up the Wellbrook loop.  I think I'll ask Wayne at Elecraft if he would consider modifying the ACC2 IO option to make it locked, requiring a long press of the RATE button on the KX3 to unlock it.  Then I'd feel really safe.

Now this is all done, I suppose I should get on and make some QSOs.  It has been a while.

New Wellbrook loop reveals significantly more contesters.

Here's a pic of the professionally installed new Wellbrook Loop here.

I nailed a spare mast post into the ground with a mallet and duct-taped the loop to it.  Some self-amalgamating tape applied to the coax connector and it was good to go.


This pic shows some of the contesters on 40m, being received on the new loop.

The change in the waterfall shows what happens when I switch back to the Diamond BB6W wire antenna.  The loop is mounted at ground level and is underneath the wire antenna.

The next screen shot shows the power spectrum with the BB6W feeding the SDR gubbins, which incidentally has my KX3 at the front end thanks to ghpsdr3-kx3-server.

The results are equally if not more impressive on other bands, but less significantly so on 15m and up.


I'm very impressed so far.  It really is good!

More pics. Now of 60m.  You can see an Olivia transmission with an RSID start up in the middle of the spectrum.  This one shows the power spectrum from the loop.

 This one shows it for the BB6W.

Note that the power spectrum is un-calibrated and that the waterfall adjusts its gain automatically.  I tend to crank the gain up on the KX3 with the preamp to lift the noise base up above the artefacts of the sound card, so I don't get distracted by them in the waterfall.

The next shot is a different instance of QtRadio, coincidentally also on 60, but this one is using my FCD-Pro+, also fed from the Wellbrook loop and has an instance of fldigi decoding the Olivia.

Some more pics from 80m.  This one is the power spectrum for the loop.

And the BB6W on 80m next.

ghpsdr3-kx3-server available on github

Having fiddled with fcdpp-server.py to add a ppm offset option before Xmas, I'd been wondering about bodging it to work with my KX3 as an I/Q source.

I had a go earlier this afternoon.  It took all of 10 minutes of python hacking to get something that functioned.  A few more minutes were spent adding command line options.  Now ghpsdr3-kx3-server is available on github.

I hope someone finds it useful, although it is receive only.

Happy new year, everyone.

KX3 UHF Emissions

I've written his blog post primarily as a place to store my screen shots related to a topic that I initiated on the Elecraft mailing list about the UHF emissions I have noticed emanating from my KX3. The full topic thread can be seen here. 

These screen-shots have been taken using osmocom_fft, with my USRP-B100 and WBX daughterboard connected the discone antenna in my loft.  My preamp is set for 0dB gain, the USRP gain is set to a total of 43dB which is about as high as I tend to set it in order to avoid intermod.

The first few pictures are with my KX3 in its normal position with its normal cable connections, in its normal configuration, set to 7.080Mhz.  The cables are smothered in #61 ferrite.

Firstly a 8Mhz spectrum capture  (below) shows a fairly high noise floor due to the bandwidth and a faint trace of the sproggy (in the centre), but some other signals towards the upper end of the spectrum, probably TETRA stuff or similar.

Next, the same scenario, but with 125kHz sample-rate/bandwidth to drop the noise floor.

Note that averaging is enabled in all of these plots.  The next one had peak hold enabled so that we can see the effect of sweeping the VFO on the KX3.

Just a quick recap, the above pics shows the results of my attempts so far to suppress the UHF emissions externally.  Perhaps I could do better.

The next picture is with the KX3 disconnected from everything, but sat in the same location.

The next picture is with the KX3 relocated to the kitchen, about 30 ft away from it's operating position.  Both of these locations are roughly equidistant from the discone antenna in the loft, which is about 30ft away.

This one is with the KX3 relocated upstairs, to within 8ft of the discone antenna. There are still no cables attached.

I then moved the KX3 back to its normal operating position, the same scenario as the 4th picture.

I then insert the right angled 2.5mm to in-line 3.5mm stereo adapter cable, which is about 6 inches in length when straight.

This time, I have two turns (they just fit) of the 2.5mm to 3.5mm adapter cable  around the mix #61 ferrite toroid. The peak hold is left from the last shot, so we can see the improvement.

Finally, the KX3 is restored to its normal state of connectivity, with antenna,  power, CAT via Acc1, I/Q, audio out and in cables attached.  I have 3 toroidal chokes with various numbers of turns on the I/Q cable, and a bunch of snap-ons with a couple of turns and the remaining toroidal chokes smothering the other cables. This time, the sample-rate is increased to 1MHz, and I have enabled the 8kHz Rx Shift, which moves the sprog down 55*8kHz, to the left hand end of the spectrum.  An unrelated signal appears to the right of the relocated sprog and a peak trace of another unrelated signal appears near the right hand edge.

Update:

So far, I've found spurs on (some of) the 10th, 20th, 40th, 55th, 75th and 100th harmonics of various VFO frequencies. With my VFO on 21.25Mhz, I'm getting an S-band spur on the 100th harmonic at 2.125GHz.

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.

PSKmail with the KX3

I've been dabbling with PSKmail over the past few weeks, using my KX3 and a variety of antennas, operating on 10.148MHz as G0HWW-5.

The new jPSKmail client 2.0.x has an embedded modem, but I like to run fldigi in waterfall only mode too, as I get better awareness of what is going on around the PSKmail frequency and how the rigs filters are set up.  I'm also using Xastir to plot stations heard.

So far I've managed to add mail records to 4 servers, DL4OAH-8, SM0RWO, OE5RTL and DL9YCS-3.

This map shows the PSKmail servers that I've connected to and configured my mail settings with.


I've been using an indoor Alex Loop Walkham mag loop and more recently an indoor NORCAL doublet, with the KX3 running at a massive 8W.

This map shows all/most/some of the PSKmail server's and clients that have gated my beacons to the APRS-IS, and of course PA0R, Rein's last reported position.

HF DRM Broadcast with KX3 and Dream

I've just got Dream working with my KX3's I/Q output and have been able to receive the "Voice Of Nigeria" DRM transmission on 15.120MHz.

Feeding baudline with the KX3's I/Q Output

After someone mentioned in ##rtlsdr that it was possible to pipe I/Q data into baudline via stdin, I wondered if I could do the same with I/Q data from the KX3.  As I'm already feeding the I/Q data from the KX3 into gr-kx3 using pulseaudio, I needed to use pulseaudio as the source for baudline but it isn't supported, so I used parec to pipe the I/Q signals into baudline.

#!/bin/sh
# blkx3 - a bash script to feed I/Q data from a pulse audio device into baudline

SAMPLE_RATE=48000
BL_BIN=~/bin/baudline_1.08_linux_x86_64/baudline

parec --format=s16le --channels=2 --rate=$SAMPLE_RATE --latency-msec=5 | \
$BL_BIN -scrollcontrol -record -stdin -channels 2 -quadrature -samplerate \
$SAMPLE_RATE -basefrequency $1

You may need to change the path to baudline in the script and maybe also the sample rates. The script takes the baseband centre frequency as its only parameter.

$ blkx3.sh 7184500

More buttons in gr-kx3.

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

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.

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.

fldigi, kx3 and pskreporter.info

I discovered pskreporter.info last night.  It is a very handy tool. The KX3, Signalink USB and fldigi running on my Linux laptop are working nicely together.  The pskreporter site shows monitoring stations that have received my digital mode  transmissions and/or transmitting stations that I have received and decoded digital mode transmissions from.  Cool!

My KX3 has arrived

My shiny new Elecraft KX3 (#01685) arrived on Monday morning.  I'm thoroughly impressed with it.

I haven't had a QSO on HF for just over 6 years, so it is unsurprising that I have no contacts to report with it, however as a receiver it is performing very nicely indeed.

My current HF antenna is a Diamond BB6W, slung low at about 12 feet AGL. I have an LDG Z11 Pro ATU nearer to the antenna feedpoint than the rig, so I'm now using it in preference to the internal ATU, which did however tune the antenna to a lower SWR.

Last night I heard VP8NO, in the  Falklands Islands on 18.105MHz using 45 baud RTTY.  The KX3 decoded it fine and I monitored the traffic using the KX3 utility on Linux.  This morning I heard VK4ZD in Australia on 17m on SSB.  This receiver is excellent.

I've also got the I/Q output from the KX3 feeding an old Griffin iMic USB soundcard and can monitor 48kHZ of spectrum with gnuradio-companion.

So far, so good :)