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.