28 October 2012

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.

4 October 2012

Sample rates, Signalink USBs, wspr and transmit audio issues

Well, wspr has been running and seemingly working ok on my Ubuntu 12.04 x86_64 machine for a few days, but I still have an unresolved issue that causes me some concern.  Whilst this issue doesn't prevent wspr from working, it does cause a crackling, popping noise to be added to my transmitted audio.

To be honest, I'd noticed this once before, when transmitting pks31 though my Signalink USB  and on out through the new KX3.  I heard the noise on the KX3's sidetone, but then forgot about it after reducing the monitor volume.

I heard it again when monitoring the wspr transmission on another radio, and resolved to track down the cause.  I've also been having other issues with Pulse Audio on Ubuntu 12.04 x86_64 so had a strong bias towards an assumption that the problem lay in the OS itself (or some part of the sound system).

However, I was using PortAudio for both wspr and fldigi, so it seemed unlikely that Pulse was the direct cause. Restarting the pulse audio daemon didn't seem to help.

I wondered if the slightly unconventional wiring arrangement between the KX3 and the Signalink USB might be allowing RF feedback into the audio circuits in the Signalink, so I disconnected it completely from the radio and switched the speaker I've been using from the Aux output of the Signalink to the Moni output, so I could monitor the TX audio.  Sure enough, the popping noise was still present when wspr transmitted. Not an RF issue then.

Someone on the LHS podcast forum asked if the popping noise was present on other audio outputs.  I reconfigured wspr to use the laptop's speakers as an output and the signal sounded clean.  They also suggested checking sample rates for the soundcard configuration. I found that wspr seemed to have no method for setting the samplerate, but after some googling discovered that it 'expected' a sample rate of 48kHz.  I wondered what sample rate fldigi had been using and noted that it was using the default sample rate for the soundcard (the Signalink USB), which I then determined to be 44.1kHz.  I then confirmed that I still got the popping noise on TX audio from fldigi by invoking the Tune function.  Switching fldigi to use a 48kHz sampling rate cured the popping noise.

Wanting to be sure that this wasn't a fluke, I fired up gnuradio-companion and sketched out an AF signal generator that could run at different sample rates (see image below).



Using this as an audio signal generator with the Signalink USB device, I confirmed that with a sample rate of 44.1kHz the popping was present, but at 32kHz and 48kHz it was OK.

I thought it weird that wspr required a 48kHz sample rate but seemingly didn't use one.  I took a look through the wspr code and it seemed to request 12kHz for transmit and 48kHz for receive audio streams.  I tried to debug it, but gdb wasn't having any of it.  Being a mixture of python, fortran  and C I wan't surprised.  I wasn't that keen on it myself, but each to their own :P

I confirmed though that  the signalink did in fact seem to be set to 48kHz during transmission:

darren@len:~/src/wspr$ cat /proc/asound/card1/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 1
rate: 48000 (48000/1)
period_size: 8192
buffer_size: 16384
darren@len:~/src/wspr$ cat /proc/asound/cards
 0 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0xf1600000 irq 45
 1 [CODEC          ]: USB-Audio - USB Audio CODEC
                      Burr-Brown from TI USB Audio CODEC at     usb-0000:00:1d.0-1.2.4, full speed
darren@len:~/src/wspr$ cat /proc/asound/card1/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 1
rate: 48000 (48000/1)
period_size: 8192
buffer_size: 16384

During reception, it was also set to 48kHz:

darren@len:~/src/wspr$ cat /proc/asound/card1/pcm0c/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 1
rate: 48000 (48000/1)
period_size: 8192
buffer_size: 1638
Note that checking the TX settings reads the pcm0p (playback) values and the RX settings are from pcm0c (capture), both from card1 in my case.  If you check the settings for the playback stream whilst wspr is receiving (and vice versa) the streams are reported as closed.

Currently I'm stumped.  Whilst wspr seems to work OK, transmitting a noisy signal is something I'm not keen on, so I think I'm done with it for now, until the issue is resolved, somehow.


2 October 2012

wspr at last

Finally I got wspr built and running on my Ubuntu 12.04 64-bit machine.  Wonder if it will hear anything overnight.

Didn't have to wait long.  I returned to the wspr window for one last look before
 heading to bed, and I see a decode.  Woot :)