Saturday, May 19, 2007

Seen at Dayton Hamvention, 2007

Photos without comment from the Dayton, Ohio Hamvention, 2007. (Click for high-resolution versions.)









































Sunday, May 06, 2007

Is Ham Radio like a Telco?

Thanks to Slashdot for the following provocative video link. Van Johnson talks to Google about what comes after the TCP/IP Internet. In a nutshell, we have seen telco-style circuit switching morph into the current TCP/IP packet switched network, and the goal has always been to support end-to-end conversations. But the current Internet is dominated by fetching data (e.g. web pages), and TCP/IP is poorly suited for it. What will come next?



This talk leads me to ask what is "amateur radio" all about? Is it a way of supporting conversations? Of course, but is it more than that? Are we stuck in the telco model, a 100 year old paradigm? It is a problem if we are a hobby that only cares about "the wires" - or the airwaves -- and not about any higher level functionality. Food for thought.

Wednesday, March 14, 2007

On Older Rigs

Recently, I had a QSO with GP0STH, Ron, on Guernsey Island. Nice to have that new country! He gave me an unsolicited "great audio" report. Now, that was interesting...

I had just resuscitated my 30 year old Kenwood TS-520S to see how well the old rig was running. The Orion was sitting quietly on my desk.

The funny thing is that the Orion is well-known for great audio, and my Kenwood and its stock MC-50 microphone is not. But the Kenwood is the one that got that report. And its market value is about 1/15th of the Orion's!

Of course the Orion Rx is a lot better in difficult conditions, but on that day on that band (20 M), the '520 got the credit.

Friday, March 02, 2007

Among the kernel developers

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.]

Sunday, February 18, 2007

Birth of an Icon


Inkscape is a cool, open-source and free program for vector graphics drawing. It produces output in the SVG (scalable vector graphics) format, which is human-readable XML, and which can be used directly in future web pages. (Version 2 of Mozilla/Firefox, for example.) Inkscape is available for Linux, Windows, and Mac OS X.

I'm not a graphics pro by any means, but I was able to put this program icon together without much trouble. This is for our new project at rigserve.sourceforge.net.

Friday, February 16, 2007

New Rigserve Project on Sourceforge


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

Upgrading the Blog

I finally made the leap into the new Google-authenticated scheme on blogger.com. It was a good thing I did, because I found quite a number of user comments for the blog that were pending. All moderation requests were going to an obsolete email address.

Apologies to readers who made great comments along the way. They should now be posted.

-Martin

Thursday, December 07, 2006

Experiments with picopower

On a recent evening at the W1YU Club at Yale, we had a program on QRP operation. That got me thinking. What equipment do I have for QRP work?

Well, I have an Elecraft XG-2. It puts out a fairly well calibrated 50 μVolts into 50 ohms. That is about 50 picoWatts on 20, 40, or 80 meters.



So here is my QRP transmitter. All it needs is a CR-2032 battery. I find it is tricky to send CW with the power switch, so I attached an old straight key. The coax goes to a 3-element SteppIR at 40 ft.

What can we do with 50 pW on 20 meters? First, try listening for it on my main rig, the Orion using a 40 M dipole. There it is, about S2 on 14.060 MHz. It is stronger if I aim the beam south, toward the dipole.

I tried a quick "CQ" just in case... But the band was dead. No response, no surprise!

Next I tried using my Icom R8500 set up temporarily in the car, with a 15 foot wire strung out over the trunk. The '8500 is not a great CW rig - it doesn't even have the narrow filter, but otherwise it fills the bill.

First test: yes I can hear the signal in my driveway, about 60 ft from the beam. I drove away to a point about 300 M away and gave a listen. (Auto noise was hopeless - I had to shut off the Acura completely before I could get near the noise floor.) Nothing at 300 M. Drove closer and closer, but still nothing positive. Finally, the signal was there at S1 about 2 houses away from mine -- maybe 50 M. It would have been usable for a QRS CW QSO.

(If we had a more appropriate receiver filter system and receive antenna, we might have gotten 10 dB more sensitivity.)

OK - if 50 meters is the range for 50 pW, what can we calculate? How about if we had 50 microwatts instead? That's a million times more power, and the square root of a million is 1,000. (We assume the inverse square law works, although really we're in the near field at only 50 M separation.) So what range would we expect for 50 μW? A thousand times more -- 50 kM or about 30 miles, at least for free space line of sight.

One day, I may throw together a 50 μW "QRO" rig to check this prediction.

Another calculation: 50 M is 28.6 milli-miles, so we have 571 million miles per Watt. It wasn't a two-way QSO, but would this be a record?

[Miles per Watt, as others have noted, is a nonsense ratio. For a constant signal to noise ratio, "miles" will vary with the square root of power, not linearly in power. In other words, the record should go to the QSO with the highest "miles per square root of Watts".]

[5/22/08: Photo restored.]