Trackpad RFI

Having spent the long weekend at my Mum's place, I threw up a random wire and counterpoise so I could have a listen with my KX3. 

Even at such modest QRP levels, there were a couple of incidents of transmitted RFI.  Transmitting on most of the HF bands apparently turned her bedside lamp on and off, and would bring her PVR in the living room (where I had deployed the rig) out of standby.

It wasn't all a one way thing though.  As soon as I connected up the rig, I remembered that I'd been obliged to procure a pair of  Powerline Networking adapters for her, so she could watch VOD on her TV.  I also remember the caveat I made at the time of purchase, which was that those things would probably always be disconnected if I came to visit with radios, so they got unplugged without any disagreement from Mum.  However, the broadband hash from her Panasonic TV was unexpected and very harsh on 20m and below.  This limited my listening to the late evening after Mum went to bed, which was also not a problem.

However, the most profound RFI issue seemed to be self-inflicted.  My Lenovo Z570 laptop's trackpad went batshit crazy when I tried to beacon on 30m with PSKmail and didn't recover when transmission ceased.  I was able to exert control over the UI with the USB mouse and eventually found the solution, namely reloading the drivers.  The commands to do this are below.  The main reason for writing this post is so that I can remember them ;)

sudo rmmod psmouse

sudo modprobe psmouse

Intriguing quirk in gqrx

I was experimenting with using my USRP B100 and a BasicRx daughterboard tapping the IF output of my AOR 8600Mk2 reciever in order to monitor the transmission quality of my Elecraft KX3 the other day.

I became concerned that my KX3 was misbehaving when I saw some fairly horrible signals in the waterfall, for example, the CW transmission below.

Horrible isn't it!

I noticed similar nastiness for SSB transmissions too.  Then, by a stroke of luck I retuned gqrx's demodulator away from the signal and much to my surprise, the nastiness went away.

I then resorted to using a gnuradio-companion flowgraph instead and the KX3's transmissions looked clean

I'm not sure what is going on in gqrx that such a quirk can exist and I haven't had a look at the code yet.  I wonder if there might be a recursive filter operating on the same data that is being used in the waterfall and PSD plot, or similar.

Update 1
I've added another screenshot below. When this was taken, I'd been scrolling the modem back and forth across the CW signal.  This time I used a modem with a wider bandwidth.

 

Update 2:

It seems to be related to the squelch somehow. In the following screenshot, I alternated the squelch between fully open (previous setting) and fully closed.  The spurii seemed to go away  when the squelch was closed.

Update 3:

Turning AGC off gets rid of it.

Approaching digital mode nirvana

Today I found myself running two instances of fldigi alongside WSPR and WSJT, all happily using the same SignalinkUSB soundcard interface to my KX3 and sharing access to the rig via Hamlib's rigctld.  Well, all but WSJT which doesn't have hamlib support in this build.

First signals received on 6m

I've just received my first signals on 6m with my KX3 and an indoor NORCAL doublet. I heard ES5RY calling CQ in CW on 50.0856Mhz.

 

Testing the AX.25 CL for DTN2

I received an email suggesting that I might like to test the AX.25 Connected Mode Convergence Layer for the DTN2 reference implementation, as some tweaks had been made to it upstream.

I updated the DTN2 source code on the two Linux machines that I use for testing the AXCM-CL with and rebuilt it.  The shack PC (upstairs) is hooked up to an FT-817 transceiver using an SCS Tracker/DSP-TNC.  The FT-817 uses it's rubber duck antenna and operates at the lowest power setting. Meanwhile, downstairs, my Lenovo laptop is hooked up to a Kenwood D72 (a hand-held radio with a built in TNC), also operating at its lowest transmitter power setting and using a short stubby dual-band antenna.

For monitoring the traffic, I decided to use my USRP & WBX daughter-board combo, using the Software Defined Radio program gqrx to demodulate the narrow-band FM signals and decode the 1200 baud AX.25.  This also runs on my Lenovo laptop downstairs, leaving me free to avoid entering the messy shack.

Here's a screen-shot of some AX.25 shifting a 35kB adif format log file on 70cm using the dtncp utility.

I pushed the adif file from the laptop to the machine upstairs and then onto the node at delaytolerant.net by means of a TCP convergence layer connection, where it was received by the dtncpd utility.  I confirmed that the md5sum of the file payload matched that determined at the sender manually.

Here's the result of probing the test network using dtntraceroute to a wildcard address:

darren@len:~/dtnrf$ dtntraceroute -e 3000 -w 6000 dtn://*/ping
source_eid [dtn://g0hww-6.dtn/traceroute.14414]
using default replyto
dtn_register succeeded, regid 25
dtn://g0hww-6.dtn/traceroute.14414: sent at Fri Feb 15 16:44:07 2013 UTC
dtn://g0hww-6.dtn/ping: echo reply at Fri Feb 15 16:44:07 2013 UTC (342 ms rtt)
dtn://g0hww-6.dtn: delivered at Fri Feb 15 16:44:07 2013 UTC (386 ms rtt)
dtn://g0hww-6.dtn: forwarded at Fri Feb 15 16:45:42 2013 UTC (95138 ms rtt)
dtn://g0hww-7.dtn: received at Fri Feb 15 16:45:33 2013 UTC (97749 ms rtt)
dtn://g0hww-7.dtn/ping: echo reply at Fri Feb 15 16:45:33 2013 UTC (99882 ms rtt)
dtn://g0hww-7.dtn: delivered at Fri Feb 15 16:45:33 2013 UTC (106687 ms rtt)
dtn://g0hww-7.dtn: forwarded at Fri Feb 15 16:45:33 2013 UTC (113715 ms rtt)
dtn://hambone.delaytolerant.net: received at Fri Feb 15 16:45:34 2013 UTC (116127 ms rtt)
dtn://hambone.delaytolerant.net/ping: echo reply at Fri Feb 15 16:45:34 2013 UTC (118282 ms rtt)
dtn://hambone.delaytolerant.net: delivered at Fri Feb 15 16:45:34 2013 UTC (125148 ms rtt)
dtn://g0hww-7.dtn: received at Fri Feb 15 16:45:39 2013 UTC (135215 ms rtt)
dtn://hambone.delaytolerant.net: forwarded at Fri Feb 15 16:45:39 2013 UTC (142659 ms rtt)

This overlapped with the file transfer using dtncp, resulting in some head of line blocking and an RTT of about 2 minutes.

No testing of the DTN would be complete without firing up what might be called a killer app for this specific domain, my awful dtnchat application, available here.

It looks like the screenshot below (which is the nicest view, the Preferences tab is even worse).  It does work though. It uses wxPython and the DTN2 Python bindings.

  
This is me talking to myself through the DTN over AX.25. The hideous notification at the bottom is probably due to it coming via a remote X session over SSH, along with the application instance on the right.