Qtel and svxlink in Gentoo

Hi all…

It’s been a long time since I took over the maintenance of svxlink in Gentoo, and to be frank, I’ve done basically nothing with it because for the most part, it worked. Much development has gone on upstream, however no newer releases have been made, the only way to get the latest stuff is via SVN. This includes the somewhat experimental Qt4 branch.

Since Qt3’s demise, we’ve had to drop Qtel from the package… prompting bug #336993. There are also issues with initialisation scripts (bug #335307).

Consequently, I decided to try out this new Qt4 branch from SVN. For those playing along at home, the installation instructions are simple enough:

$ svn co https://svxlink.svn.sourceforge.net/svnroot/svxlink/branches/qt4/
$ cd qt4/src
$ make
$ sudo make install

At first, I found it wasn’t working… completely deaf and mute.  Vox didn’t show any sign of hearing my audio from the microphone… and I couldn’t hear anything back.  I tried some other ALSA devices… at this point Qtel only supported one audio device at a time.  Some tinkering, I found I could get it to hear me, but audio was very scratchy.

I had noticed this with aplay too… the problem being that the audio CODEC on the Yeeloong runs at 48kHz, and does not support other rates.  I managed to set up dmix to enforce a 48kHz rate (and give me software mixing as a bonus), then set up a rate converter atop this… but a snag, you can’t record from dmix, and Qtel (or rather libasyncaudio) expected a two-way device.  I suggested to Tobias that having separate microphone and speaker devices would be a good idea.  In double quick time he had updated the Qt4 branch to support this.

Some tinkering, and I managed to get it to hear me, but I was still effectively deaf.  It took some more investigation to track down some of the other issues, but eventually this morning I cracked it.  I had working audio both ways… but received audio was still very scratchy.  Further testing with aplay, after thinking I had solved the problem confirmed this.  More fooling around with .asoundrc ensued.  I finally tried an upgrade of the kernel to 2.6.36-rc7 (linux-loongson-community git HEAD).  Voila, rate converted sound out of aplay came through crystal clear.

I started Qtel and tested it initially on *ECHOTEST*, then on a local repeater (VK4RBR-L node 284321 / 147.950MHz FM) listening via RF as well. No problems there, it seems to be able to make contacts no problems at all. I will have to try svxlink itself at some point to see if I can successfully construct a node using the software, but for now my own node is back on the air after a long hiatus… and I hope to have new ebuilds in the tree.

In particular, svxlink will be split into a few packages.

  • dev-libs/libasync: Asynchronous I/O Library
  • net-libs/echolib: Echolink Communications Library
  • media-radio/svxlink: svxlink and remotetrx
  • media-radio/qtel: Qt Echolink client

I should probably try it on the O2 as well, but Qtel, libasync and echolib will probably get keyworded ~mips too, since they work fine on the Yeeloong   The others… well, I’ve got the parts to make an interface cable for the FT-897D here, in fact, enough for two.  The plan is to make up this interface cable, and try setting up a node on FM simplex.

There’s a second ‘897D as well… however it has a burnt out microphone preamp after a storm blew it up (and a blown up DDS chip, so no SSB or AM TX on this rig).  Miraculously, its finals seem intact as it’ll happily blast out 50W RF on 2m (with no modulation).  If the data interface works okay though, it may work well enough for a temporary 70cm node on one of the local repeaters, VK4RBC Mt. Coot-tha.

In the meantime, my personal node is now up and running again after a long hiatus… Look for VK4MSL in your client or dial  37 37 40 via RF.

Obligatary screenshot of Qtel in action

Obligatary screenshot of Qtel in action on the Yeeloong