Just testing...
This entry comes to you through the "gnome-blog" posting program from my Linux environment. If you can read this, it does work.
I have also tried BloGTK 1.1, which looked even more promising, but it does not seem to give good results with Blogger.com sites, which this one is. It does not treat titles correctly, for example.
Note added: Gnome-blog also appears unable to set an article title. So, maybe it's not going to work out.
Here's an old-fashioned (CLI-based!) but useful Python program that lets you create mailing labels and examine and dump records from the QRZ.com XML database. (Online.qrz.com account required.)
The program is developed for Linux and other Unix-like environments, but could readily be adapted for other operating systems.
For mailing labels, qrzpy supports 3 x 10 standard stick-on label stock for your LaserWriter or other printer. Alas, the QRZ.com address data may sometimes overflow the space available (see photo), but such exceptions are reported to the user.
Like most of my Python adventures, it's about the journey of discovering how to do things and perhaps to help others figure out Python programming -- as much as it is the final product.
See my software page www.aa6e.net/software for further details.
When working PSK31 or other "digimodes" on HF (high frequency) radio, we commonly use computer soundcards to analyze and transmit data. I like to use the Linux program fldigi for this, along with my Ten-Tec Orion transceiver.
The soundcard takes in the entire audio output from the Orion, typically 100 - 3,000 Hz. Fldigi (and similar software) allows you to point to a transmission of interest on a "waterfall" spectral display. This automatically sets the decoder to analyze data in a small band around the cursor using digital filtering.
This works well when the bands are relatively quiet, but when you have a band crowded with strong signals, the signal of interest can be strongly affected by "out of band" signals (but still in the 3 kHz audio region) that key the receiver's AGC (automatic gain control).
In this case, we need narrower IF (intermediate frequency) filtering than 3 kHz. Fortunately, a DSP (digital signal processing) rig like the Orion provides "infinitely" adjustable IF bandpass characteristics, so it is possible to "zoom in" on the signal of interest, largely rejecting any signals outside the small IF passband.
I have written a small Python/wxPython application "oFilter.py" that puts up a panel to allow Orion bandpass control from the same screen as fldigi. (Since fldigi communicates with the Orion via Hamlib at the same time as oFilter, there is a small potential for I/O conflict, but this is not a serious problem.)
Here are a few screenshots to show what is going on. Ultimately, it would be great to integrate the oFilter functions into fldigi or a similar program, using convenient mouse controls.
About 200 hams and friends gathered at the 26th TAPR/ARRL Digital Communications Conference for 2007 was held in Windsor Locks, CT, Sept. 28-30, 2007.
Many great papers and conversations. I presented my talk (PDF), "SourceForge, Hamlib, and Rigserve: Free Beer, Free Speech, and Rig Control", which is also printed in a somewhat different form (PDF) in the Proceedings.
A few cheap photos from my Treo 650 phone:
My contribution for the TAPR/ARRL Digital Communications Conference, Sept., 2007 appears here, as a PDF.
DCC is always a good show for advanced Amateur Radio technology. This year, it will be in Windsor Locks, CT, not too far from me. Previous Conference Proceedings are available.
Along with a number of other Linux users, I noticed that my Keyspan 49W 4-port USB serial converter stopped working when Fedora Core 5 updated to kernel version 2.6.18 late last October. Ever since then, I have not been able to update to the latest kernels. So, I reported the bug to Fedora's bugzilla (#21300), and sat back to see what would happen.
The bug percolated through the Fedora and Linux kernel support channels. At the end of December, I got word that the bug was probably found and a patch was put out for testing and inclusion into the Linux kernel. (I realize that if I really needed to use the latest kernels, I could apply the patch and compile driver for myself, but the fact is I don't need it that badly.)
Now it's March, and the patch has still not found its way into the mainstream kernel, as far as I can tell. I did not know what to expect from the process, but it does seem that progress is being made.
This post is really about my latest interesting discovery on this subject: a colloquy among the kernel guys about the progress of the patch. It gives a little insight to how things happen in the kernel world.
I do appreciate that people are working on "my" problem!
[Note added 3/16/07. The latest Fedora update included kernel 2.6.20-1.2300.fc5, which seems to incorporate the Keyspan patch.]
Some of you know that I've been working on "Rigserve", which is meant to be a much streamlined server-style application providing much of the functionality of Hamlib. We avoid most of the cross-platform problems by defining our API over an IP connection, which is human-readable and even testable over Telnet. Rigserve is implemented in object-oriented style using Python, which should allow it to run on many platforms. I am not sorry to jettison low-level C, the GNU Automake stuff, SWIG, and all that!
We have talked about the relationship of this development to Hamlib. Should we think of it as a candidate for "V2 Hamlib"? Well, Rigserve is not a library, and there is no backwards compatibility. Rigserve does share some philosophy with Hamlib, but that's about it. I have concluded that it should stand on its own, but we should give full credit to the many folks who have brought us Hamlib as we have it today.
[There are some alternate approaches, too, such as XML rigCAT descriptions at http://w1hkj.com/xmlarchives.html . These may be useful to both Hamlib and Rigserve down the road.]
There is now a project at http://sourceforge.net/projects/rigserve with a slightly updated version 0.21 available for download. The files are managed in the Subversion (SVN) repository.
I would welcome anyone who wants to contribute to rigserve to join this project. There shouldn't be a conflict of interest here, because the intersection of hotshot C and Python programmers is probably limited. Though I am neither(!), I will continue to support the TenTec Orion for Hamlib.
It has been interesting to start a Sourceforge project and to learn Subversion and the other tools. Frustrating, too, because SF's shell server and compile farm chose this week to go into meltdown. The project web page is at rigserve.sf.net.
73, Martin AA6E
Rigserve is a new approach to local and remote control of ham rigs, inspired by work on Hamlib. Rigserve is an IP network server, programmed in Python, that provides a simple text-based interface to control an arbitrarily large number of rigs. The code is compatible with Linux-like OSs and Windows. Rig backends are provided initially for the Ten-Tec Orion (I and II) and the Icom R8500.
See hamlib-developer.blogspot.com and www.aa6e.net/aa6e/software for more information.
The Hamlib project has been working on a rig-independent API for software developers that will allow them to connect to a wide variety of ham rigs without worry about their individual interface quirks.
Lately, we have begun discussing how this project can envolve into a "version 2". There is a new blog at hamlib-developer.blogspot.com to support development of Hamlib. If you want to take an active part in the Hamlib project through this blog, please contact me.
The Hamlib project is supported at sourceforge.net/projects/hamlib, which provides a mailing list, CVS, and other amenities.
If you're a hard-core Linux ham and you want to use the ARRL's "Logbook of the World" (LOTW), you are in for some work. The Linux binary software distribution is provided only for Fedora Core 3 distribution, which is now well out of date. You have to compile from source code, and even the source code is out of date with respect to current (Fedora Core 5) compilers and libraries.
Here is my cookbook recipe for how I did it on my FC5 system. I believe I've incorporated all the steps, but I would welcome your feedback if you try to replicate the results.
Fedora Core 6 is right around the corner, and FC6 may possibly require further modifications.
Added Note: The procedure has been found to work as recently as the Fedora 8 release. (12/2007)
A new Python-based Tone Generator application is available from the AA6E software library at www.aa6e.net/aa6e/software/tone. It was a learning exercise for me to get acquainted with the wxWidgets cross-platform library for software development. We are also using the wxPython library that provides a Python "wrapper".
The present version is for Linux and Unix only, since it makes use of the OSSaudiodev module for sound generation.
Tone will work with dual soundcards, and will provide single or dual tones with sine-, square-, or triangular-waveforms. It can be useful for many kinds of system tests, including intermodulation distortion.
A great feature of Amateur Radio is the range of activities you can join in. Everyone can find a home with some operating style or technology work. Some of us combine on the air work with computer programming.
I’ve found a particular corner of ham radio called the Hamlib project, initiated in 2000 by Frank Singleton (VK3FCS/KM5WS) and Stéphane Fillod (F8CFE) and supported by dozens of hams around the world. The Ham Radio Control Libraries are intended “to provide a consistent interface for programmers wanting to incorporate radio control in their programs.” This project is an example of “free and open source software”, developed by a large group of people who volunteer their time. You’ve heard of Linux and the Mozilla and FireFox browsers? They were created the same way.
You may know about “software defined radio” (SDR). That’s not what Hamlib does. Hamlib manages the control functions of radios, including DSP and SDR rigs, but it does not do signal processing itself. Hamlib is largely developed in the C language under Linux, but it is adaptible to other operating systems (MacOS, Windows) and languages (C++, Python, Perl and others).
If you’re a programmer using Hamlib, you can write applications to work with many current and older radio devices that permit computer control. This is a big benefit, because you can spread your time investment over the greatest number of potential users. Most radio control packages today are written for specific devices (“rigs”), but the potential “market” for software for one radio model is always limited. Even hams who write “free” software think about market share!
The Hamlib project is ambitious, aiming to support over 200 rigs and variations, ranging from scanners and shortwave receivers to exotic computer-based DSP transceivers and some antenna rotators. The strategy (Figure 1) is to provide a library that adapts many different radios to a higher-level application program. If you are a typical ham who is not a programmer, you can download a software application package that is built “on top” of Hamlib. A number of Linux applications are already available for digital mode support, logging, etc. Check the Hamlib web site at http://hamlib.sourceforge.net .
Figure 1: Hamlib is the “glue” that connects applications programs to ham rigs.
Hamlib is tackling a big problem. How do you provide for scanners with a thousand memory channels, priority sampling, and so on in the same program with multi-band VHF transceivers and computer-based DSP HF radios?
The problem is not as bad as it might be, since rigs tend to fall into categories (receivers, VHF transceivers, HF transceivers, scanners, etc.) and into product families that share similar interface protocols (Icom, Ten-Tec, Yaesu, Kenwood, etc.) It is also possible to define a useful subset of each rig's functions -- at minimum. frequency, mode, and transmit/receive. For many rigs and applications, such as QSO logging, that is sufficient.
If you want to write a ham application program to talk to a radio, you have an interesting choice: Should you aim for the best possible interface for a particular rig on a particular operating system? Support a particular rig on multiple operating systems? Support many rigs, as Hamlib does, on a variety of operating systems? It's a trade-off of man-hours, features, and desired market share.
[A shortened version of this article is scheduled for publication as a "Stray" in QST.]
