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.


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.

Wednesday, July 05, 2006

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%


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" ( 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.
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.
1. Doug Smith, Ten-Tec's Orion HF Transceiver: The New Performance Standard, 2002-2003,
2. Sinisa Hristov, A test of Orion's external CW keying,
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.