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.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)
I have discovered the Analog Devices "Blackfin" DSP/controller lately. Using uClinux, you can run "real" software in this chip, with many options for I/O, including Ethernet and audio codecs. Cheap development boards and free software are pretty attractive. I am looking for anyone who is using this technology (or anything similar) in an amateur radio application.
The chip is powerful enough for a full SDR implementation, but I'm thinking more about building an intelligent controller & digital audio interface for conventional rigs.
