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.

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.

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)

SteppIR Power Consumption

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

Condition	AC power drain
Power Brick only (controller disconnected)	1 W
Controller "off"	10 W
Controller "on" (idle)	10 W
Elements slewing	30-40 W
D connector disconnected	3 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.

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.

TT Orion: Adventures in the Time Domain

Using QSK break-in on my TenTec Orion I transceiver, I observe that I can't hear much between the dits and dahs above about 25 wpm. Other hams report that they work high-speed QSK with no problems. Is the Ten-Tec Orion truly a full break-in QSK rig? What's going on here?
While operating QSK CW I fairly often run into echo phenomena. You can hear your own signal coming back to you after a very short delay. Sometimes this backscatter return is so strong that the confusion with my own sending sidetone makes operations difficult if I don't switch off QSK. Where do these echoes come from?
Both of these problems are "time domain" issues that require understanding the signal delays in my digital signal processing (DSP) based transceiver. Details of DSP programming for commercial ham gear are often undocumented or proprietary, although Orion's DSP was partly described by Doug Smith KF6DX [ref 1]. Without diving in with a logic analyzer, the best way to understand this rig was to treat it as a black box and observe its inputs and outputs. Even so, there were some interesting results, which prompts me to suggest testing labs should add a number of simple tests in the review process.
Orion's CW keying and related properties were treated by Sinisa Hristov YT1NT/VA3ITN [ref 2] and also in the QST review[ref 3] and ARRL's expanded test-result report[ref 4]. Sinisa's main concern was the quality of transmitted CW -- whether the dits, dahs, and interspersed pauses were accurately generated. His interesting results showed that with firmware version 1.369, there was a certain amount of keying pulse narrowing along with timing jitter. CW rise and fall times were also much shorter than indicated by the rig software. Some of these issues may have been addressed in later firmware revisions.
In this article, we look at a different set of measurements. What is the actual timing behavior of the Orion with regard to QSK switching? To begin, we look at a simpler issue: what is the delay time from receiver input to audio output? In DSP receivers, delay can be significant, because we use high performance digital filters for SSB phasing and bandpass control. But how significant?
Measuring receiver signal delay
It is interesting to look at the actual input-to-output signal delay of a DSP rig to get some insights. These measurements are relevant to another project of mine – measuring ionospheric echo delays using the transceiver as in “radar” mode. Receiver delay is an important part of QSK performance, and it is also important if you need to combine dissimilar receivers for diversity reception. Curiously, the ARRL lab reports did not have a measurement of receiver delay.
I set up a simple test using low-tech instruments at my home station. As a first "sanity" test, I received WWV's 10 MHz AM signal using the Orion and an Icom IC-R8500 non-DSP receiver. The WWV "tick" (5 cycles of 1 kHz tone) is convenient to look at. It is hard to sync on the tick, and there are all the usual problems with noise and fading. Despite that, it was easy to see that Orion's output was about 4 ms late with respect to the '8500. "That's not bad", I thought, but there was more to be seen.
For a more accurate look at delays, we should use a locally generated noise-free signal. Fortunately, my Tektronix CFG250 Function Generator generates a fast switching pulse output (rise/fall under 100 nS). It generates profuse harmonics through the HF range. Figure 1 shows a typical measurement, this time for the SSB mode. The pulse at the right is produced by the falling edge of the pulse, as can be verified by adjusting the pulse repetition rate. The delay from falling edge to Orion output is approximately 14 ms. All these measurements were taken on the Orion 565AT, SN 12C10493, with firmware version 1.372. The receiver delay tests were made with the sub-receiver only, but the DSP processing is essentially the same in the main- and sub-receivers.

FIG 1. Orion receiver delay. Top, pulse signal source; Bottom, Orion 565AT audio output. Horizontal, 2 ms/div.

The test was repeated for all of Orion's signal modes with the results in Table 1. The number of filter "taps" (FIR filter length) was adjusted to maximum and minimum values using Orion's menu settings.

Signal Mode	N taps	Receiver delay (ms), +/- 10%
AM, FM	199	6
	32	6
SSB, CW, FSK	199	14
	32	8

Table 1, Delay vs Receiver Settings

The Orion's actual DSP sampling rate is not published, but I infer it to be in the range 44 - 48 kHz. Taking 44 kHz, the delay values measured correspond to 264 samples for AM or FM, and 616 for the other modes. Without knowing internal details, I can only say the numbers are plausible. The SSB-like modes all require extra processing (Hilbert transforms) to carry out the phase shift operations, and the amount of extra work appears to be proportional to the selected number of FIR taps. See the tutorial by KF6DX. [ref 5]
Having done this much "science", what can we do with the QSK problem?
QSK Switching
You would think transmit / receive (T/R) switching for CW is very simple: Key down -> Rx off -> Tx on. Key up -> Tx off -> Rx on. Yes, but you need to allow time. First of all, we need to protect the Rx from high Tx power, and there may be a linear that has to be switched, too. (The Orion provides a couple of alternatives for controlling linears, but we won't consider them here.) More seriously, the Tx signal generation uses much of the same DSP hardware as Rx, so we need more time to flush the Tx data from the DSP and to load the new Rx data. Our receiver delay measurements above show that it can take up to 14 ms to get the receiver going from a dead start.
In the absence of a manufacturer's specification or a published algorithm, we will resort again to grubby measurements to see what is really happening. We will look at 20 wpm (my paltry CW speed) and 35 wpm (where the "pros" work). The measurement is fairly straightforward. This time, I was able to use a new discovery, the program "xoscope" (http://xoscope.sourceforge.net/) which implements a soundcard-based oscilloscope on my Linux computer.
The 20 wpm result is shown in Fig. 2

FIG 2. Orion audio output sending dits at 20 wpm, internal keyer.

During "transmit", the Rx outputs its monitor tone. In a separate measurement, I was able to confirm that the monitor tone accurately reflects the actual RF output timing. When the dit finishes, there is a period of silence of about 25 ms, and then the receiver begins to provide audio. This agrees with the ARRL lab reports. The receiver audio is switched off just a few ms before the next dit of RF output begins.

The Orion provides a "QSK Delay" setting that will retard the changeover from Tx to Rx. Our measurement is taken with QSK Delay = 0%, which provides the longest Rx audio window.
What about 35 wpm? Figure 3 shows the result.

FIG 3. Orion audio output sending dits at 35 wpm, internal keyer.

Only about 6 ms of receiver audio squeezes through between dits, despite the 38 ms available. Dit compression is not evident. Note that, based on these dits, the apparent code speed is 2 elements per 76 ms, which is 31.6 wpm according to the "PARIS" standard.

It is very hard to hear even a strong received signal when "chopped" into such a brief window. Of course, much longer receive segments are available in the intervals between letters and words, and many operators feel that is sufficient for "QSK" operation.
Suggestions for Transceiver Testing
These results suggest a few manufacturer specifications and lab tests that could be added to product review testing. (We always want more!) In particular, it would be helpful to specify and measure receiver delay under various conditions. The League's extended report does have data for transmit delay (24.5 ms PTT to 50% RF out in SSB), but not for receive. An important operational question, related to these delays, is QSK T/R performance. It would be helpful for lab tests to quantify QSK vs CW sending speed.
As a general matter, when a rig's performance is more and more determined by DSP and other software-like questions, the nature of lab testing should reflect this fact. In addition to delay measurements, other DSP issues, like speech processing, audio distortion and frequency response (possibly limited by sampling issues), functionality of computer interfacing options, and overall "robustness" would be helpful to many readers.
Conclusions
Any transceiver that relies on DSP technology is likely to have significant time delay issues for some kinds of rapid T/R operation. The worst normal case is for full break-in QSK, in which a perfect rig would let you hear “between the dits” up to a very high keying rate, at least 50-60 wpm. The Orion does not achieve this, although many hams still regard the Orion as a very good QSK rig. By comparison, the FlexRadio SDR-1000, which is an advanced software defined radio that relies on DSP implemented in a general purpose PC, is not capable of QSK at all in its current release, and suffers substantial key-down to RF out delay so that on-air CW monitoring is problematic.
Manufacturers of DSP rigs do not always publish the relevant specifications. The rigs support an enormous set of possible operating modes and parameters, so it is not surprising that there are few “guaranteed specifications” on the digital side. In particular, rig advertised as “QSK capable” may not give you the expected results. The internal algorithms are generally not specified, and a operational surprises may await users with each firmware release. Some users point out that publishing the DSP and control code, perhaps in an “open source” model, would be a way to inform the user community of the processing methods being used and a way to solicit constructive suggestions from the community.
While hams can measure the gross behavior fairly easily with common tools, such as an oscilloscope and function generator, it would be helpful to have more complete time-domain tests added to future lab reviews.
REFERENCES
1. Doug Smith, Ten-Tec's Orion HF Transceiver: The New Performance Standard, 2002-2003, http://www.doug-smith.net/orion.htm
2. Sinisa Hristov, A test of Orion's external CW keying,
http://dayton.akorn.net/pipermail/orion/2004-February/000256.html
3. ARRL Product Review for Ten-Tec Orion Transceiver, January, 2004
4. ARRL Laboratory Expanded Test Report, Ten-Tec Orion
5. Doug Smith, Digital Signal Processing, chapter in ARRL Handbook, 2001, and also Doug Smith, Digital Signal Processing Technology, ARRL, 2001.