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

Friday, November 17, 2006

Known by the company we keep

I see we made the big time with a listing in AwfulBlogs.

You know what the doctor says, when you say "it hurts when I do this"? He says, "well then don't do it any more."

Moving on...

Rigserve

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.

Saturday, September 30, 2006

Hamlib, reloaded

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.

DXCC at last?

After some 49 years in amateur radio, I tallied up my QSL connection and found 101 "entities". If the League agrees, there will be a new piece of wallpaper for me - DXCC. At this pace, I will be on the honor role in about 150 years.

Thursday, September 21, 2006

ARRL LOTW on Linux Fedora Core 5

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)

Thursday, August 10, 2006

SteppIR Power Consumption

Checking the power consumption of the control system of my SteppIR 3-element Yagi:

ConditionAC power drain
Power Brick only (controller disconnected)1 W
Controller "off"10 W
Controller "on" (idle)10 W
Elements slewing30-40 W
D connector disconnected3 W

(All readings were taken from a "Kill-A-Watt" device.)

It is interesting that turning the "power" on or off has little effect on AC power drain. It just shuts off the panel lights, as far as one can tell. According to Internet sources, a bias current continues to flow to the stepping motors when the controller is "off". This helps prevent the element lengths from drifting.

Wednesday, July 19, 2006

Orion Keyclick Checks

Executive Summary: The Ten-Tec Orion (original model) CW characteristics are significantly different between versions 1.373b5 and 2.056 of the firmware. The older firmware shows better CW click suppression. The newer firmware has a wider range of rise and fall times available, however, it appears that the raised cosine waveform is less accurately generated.As a software-defined radio (SDR), the Ten-Tec Orion's personality has undergone significant changes since its initial release, particularly in the recent transition from version 1 to version 2 of the firmware. I was interested in the issue of key clicks for CW work. What is the role of the Orion "CW Rise/Fall" parameter, and what is the best setting?
It is hard to evaluate key clicks without high quality lab gear, but I resolved to see what I could do with a 20 MHz scope and an Icom R-8500 test receiver. The test setup was the Orion driving a dummy load at 18.090 Mhz. The R-8500 was set up attached to a few feet of coax. The Tektronix 2205 scope was attached to the dummy load through a small gimmick capacitor. A 10 Hz symmetrical keying waveform was provided externally by a Tektronics CFG250 function generator. This corresponds to 25 wpm, more or less. Measurements were performed using both the latest version 2.056 firmware and 1.373b5, the last version 1 firmware in circulation.

First, we need to characterize the test receiver. We are operating in CW mode. Using the internal 10 and 30 dB attenuators and tuning off the Orion's carrier frequency, it is possible to check the receiver bandpass. The measured results using a CW carrier were -5 dB at 1.35 kHz, -20 dB at 1.6 kHz, and -30 dB at 1.8 kHz. In CW mode, the bandpass is symmetric around 0 kHz, so we are in rough agreement with Icom's spec, which is IF bandpass of 2.2 kHz at -6 dB.

(Disclaimer: All level measurements in this article are quite rough, relying on the calibration of the '8500 S-meter and the built-in attenuators. We are looking for qualitative comparisons that will bear on the key click question.)

Results for v 2.056

The first table shows the measured CW pulse risetime in msec. from the Orion vs. the Orion's "CW Rise/Fall" menu setting. Without a storage scope, it is difficult to make accurate measurements, especially of the fall time, because of Orion's timing jitter. We can see that the actual risetime is somewhat shorter than the menu setting.

The second table shows S meter readings at various distances from the Orion Tx carrier frequency versus "CW Rise/Fall" setting. The receive audio is predominantly from "clicks", although there are some weak birdies and other noise. (The response to a steady CW note is very small, except as noted below.) It is not surprising that there are a lot of artifacts like that, because an S1 signal indication is about 100 dB below the Orion carrier.

The R8500 is much inferior to the Orion's receiver. According to ARRL, its IP3 is about -7 dB and third order IMD dynamic range is 86 dB. Even with these limitations, the R8500 is useful for making comparisons, and it's the only independent receiver available at my QTH.

We notice that the observed click power falls off significantly as frequency offset increases. The response at 10 kHz is about 6 S-units (nominally 36 dB) below that at 3 kHz. (Rise/Fall = 3.) Surprisingly, the click power does not clearly decrease with increasing Rise/Fall setting. What's more, at Rise/Fall = 9 or 10, the response is actually increases significantly. I believe this is related to visible "defects" in the keyed transmit waveform, which appears to have a discontinuous slope as it approaches full power. It departs visibly from a smooth raised cosine. (Other experiments show that this waveshape problem may depend on Orion power level. The waveform is better at higher power settings. This suggests a possible interaction between Orion's internal ALC processing and the keying modulation.)

At 15 kHz, no meaningful measurement could be made because the R8500 output was dominated by a strong white-noise-like signal that might indicate phase noise in the receiver.

Results for v 1.373b5

A similar bank of experiments using the older firmware produced the following results.
The first result is that the range of actual rise times is from 1.6 to 6 msec, somewhat shorter than in the first test.

The second table shows a major improvement in key clicks. Click power is almost undetectable beyond 5 kHz offset. With Rise/Fall set to 7 or higher, clicks are significantly reduced (compared to a setting of 3) at all frequency offsets, and are barely detectable even at 5 kHz offset. The anomaly seen in v 2.056 at settings or 9 or 10 is not present in v 1.373b5.

Conclusions

From a standpoint of CW signal transmission, version 1.373b5 firmware is significantly better than 2.056. Visually, this seems to correspond to a cleaner raised-cosine waveshape seen on the scope. A rise/fall setting of 7 will minimize key click interference. This should be adequate for my use at 20-25 wpm, at least.

There is a strong possibility, especially with the v 2.056 firmware, that signal quality depends on power output level. (This needs further study.) Using full 100 W power seems to give the cleanest results. However, users who need to run lower power to drive linear amplifiers should watch for excess key clicks.

More careful measurements with good lab equipment would be very helpful. Unfortunately, the results can depend strongly on the firmware version. Ideally, an SDR transceiver should be recharacterized after each software update.