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

UHF Satcom - something on 252.299MHz

I'm wondering what this is:

L-band SARSAT doppler tracks in gqrx

High Altitude Balloon tracking

This might be a kind of live-blog. Perhaps. We'll see what happens.

Project info: http://ukhas.org.uk/

Tracking online: http://track.spacenear.us/

I'm using a discone in the loft and a preamp at the wrong end of the coax.  With this arrangement, I can here (but not well) some priates on UHF-SATCOM,  quite a few 70cm sat transponders and faint signals from L-Band SARSATS, so it works okish.

A screenshot of gqrx, using a USRP B100 & wbx daughterboard.

 One of dl-fldigi, using an AOR8600mk2 and a Signalink-USB.

Apparently that's PROM i can see.

Bob too now:

Now, I'm decoding Bob, but with bad checksums:

There's a bunch of loons going up, so I thought I'd monitor a whole MHz of spectrum in gqrx and look for them all at the same time, then tune in the strongest for decoding.  This is the playing field, below.  Bob is where the receiver is tuned to, and PROM is up at 434.167, faintly visible.

I popped up to listen to FO-29 and when i came back, there was another signal:

Apparently, it was TRUSS:

A little while later, I spotted ROLL in the waterfall:

 

But the decodes weren't so good as it was in a noisier part of the band:

I continued to monitor, alternating between TRUSS and ROLL depending on which seemed stronger at the time.  I didn't get many good decodes.

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.

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.

Now that's what I call ...

... a lot of CW!

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.

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.

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 :)

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 :)

Data mining with gr-air-modes and sqlite.

I spent some time doing data entry last night.  I was too tired to write a script to scrape data, so I just manually keyed in the list of callsigns and units from banterops.com so I could identify some aircraft that I couldn't track.

This allowed me to see a fair bit more info about what was in the air.

Adventures with sqlite and gr-air-modes

In the last week I've been dabbling with sqlite.  Whilst dabbling, it occurred to me that I already had a potentially interesting sqlite database to play with. I've been putting my rtl-sdr dongle to good use, and have gr-air-modes running full-time on the linux box in the shack, so I'd already collected a large ammount of Mode-S data to try mining with sqlite queries.

I figured out that probably the most interesting thing to do would be to determine which aircraft didn't broadcast their positions.

My intial attempts to get lucky with select queries yielded either a syntax error, or an empty result.  I decided to reduce the degree of ignorance that I was applying to the problem, and resorted to google.

After google hit me with the cluebat, I  cooked up a query:

SELECT ident.ident
FROM ident LEFT JOIN positions
ON ident.icao = positions.icao
WHERE positions.icao is NULL;

This produced a bunch of callsigns, but ran like a dog. As the database I was working with grew larger, I began to have locking issues and had to bodge my working branch of gr-air-modes more heavily to keep it running.

Some more googling dug up a faster query format for me:

SELECT  ident.ident
FROM ident AS ident
LEFT JOIN (select distinct icao from positions) AS positions
ON ident.icao = positions.icao
WHERE positions.icao IS NULL;

This ran much faster than my original (0.4 secs vs. 4.5 secs on a 10MB db).

I decided to create a view, stored permanently in the database, so I didn't have to keep repeating myself:

CREATE VIEW "Untracked"
AS SELECT ident.icao, ident.ident
FROM ident AS ident
LEFT JOIN (select distinct icao from positions) AS positions
ON ident.icao = positions.icao
WHERE positions.icao IS NULL ;

The view can be invoked by

SELECT * from untracked; 

I've not yet been able to get the icao column contents formatted as hex within the query results.

I'm currently going through the process of merging my gr-air-modes tweaks back to the mainline upstream, as they were originally based on the rtl-sdr fork. I've added timestamps to all the entries in the ident table, and I'm just about to bodge the code to store all received ident message instances in the database

I've been doing all of this on Linux, using both the sqlite3 shell utility, or with Sqliteman, both of which are working well. 

Quick bodge to run multiple instances of gqrx

I wondered if I could get multiple instances of gqrx running at the same time, but it seemed that the config file used at startup was hard-coded.  I contrived a quick bodge to get two instances running so I could use my USRP and my FCD at the same time.

Modifying line 54 of applications/gqrx/main.cpp to use the first argument, if present, as the config file name seems to have worked, in that it has let me run 2 instances with different config files that were previously saved.  If I give an invalid file-name as the first argument, it forces the configuration dialogue box to be shown.

    MainWindow w((argc > 1)?a.arguments()[1]:"default.conf");

A quad tilt-rotor for KSP

I've now cobbled  together an un-manned quad tilt-rotor craft for KSP.  This thing is pretty tricky to fly.