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.

Preliminary Orion "Radar" data

I was working with the Orion, trying to figure out its T/R timing on QSK CW. It turns out the dead time, from end of "key down" to receiver audio output is about 28 msec, by my measurement. The ideal QSK rig has zero dead time, so that the entire interval between key-down times is available for listening. The Orion has lots of DSP things to turn around, or so I suspect.

I did some of these timing checks on the air (low power) just to be sure we had realistic conditions. After finishing, I tuned around to what I could see on the different bands. The bands were dead -- no signals heard on 20 meters and up. Were there echoes tonight? There was nothing audible. But when I set up on 20, this is what I saw.




The horizontal time axis is 10 msec. per division. The frequency is 14.124 MHz, receive BW = 400 Hz, beam heading 110 degrees. Power is 100 W. We are looking at the AUX audio output. AGC is off. We are using the internal keyer set at 20 wpm. The bright horizontal line is the T/R dead time. The time is 0500Z, 4 Jan. 2006.



To confirm that we are seeing something from "the sky", switch the SteppIR to 180 degrees and transmit toward bearing 290 degrees. The return pulse is absent.



To see a little better what is going on, back at bearing 110, decrease the time resolution to 20 msec. per division. Here we see the two dits and the received interval between them. There is a suggestion, after looking at these waveforms for a while, that we are seeing multiple return pulses that are confused with each other after the first visible pulse. (The slope of the "dead zone" is due to AC coupling in the 'scope.)



For comparison, do the same experiment with the same bearing on 15 meters, 21.127 MHz. No effect is visible.

These photos are like a radar "A scope" view. Range increases to the right. What is the minimum detectable range? This is determined by the relatively slow T/R changeover time. The speed of light is about 5.3 msec per 1000 miles. Therefore the minimum range return echo that can be seen is roughly 5300 miles round trip, or 2600 miles down range. The delay we see here is about 35 msec (falling edge to falling edge), or perhaps 3000 miles range.

This echo return was not audible to the ear, and the range is apparently quite a bit shorter than with the pronounced returns I experienced recently with my 21 MHz New Year's contact with ZS6SIG.

Will some radio science emerge here? Stay tuned.

p.s. WWV is reporting the following:

:Product: Geophysical Alert Message wwv.txt
:Issued: 2006 Jan 04 0603 UTC
# Prepared by the US Dept. of Commerce, NOAA, Space Environment Center
#
#          Geophysical Alert Message
#
Solar-terrestrial indices for 03 January follow.
Solar flux 85 and mid-latitude A-index 2.
The mid-latitude K-index at 0600 UTC on 04 January was 1 (06 nT).

No space weather storms were observed for the past 24 hours.

No space weather storms are expected for the next 24 hours.

I.e., very low activity.

Note added (1/8/2006): Radar interpretation requires understanding the systematic delays of the equipment. Further study shows that the Ten-Tec Orion, as a DSP transceiver, has significant "processing delay" in its receive path. In modes that use the SSB demodulation, including CW, the audio output is delayed by up to 14 msec from the RF input. This will alter the range calculation, above.

(5/22/2008): Figures restored.

HF Radio Science + QSK = Radar!

When operating QSK at 15-20 wpm, I am running into echoes of my transmissions. These occur on certain azimuth bearings at certain times of day, most often to the SE, which is over water until hitting S. Africa or Antarctica from here. I've seen this from 20 M to 15 M, at least.

Rarely, I think I've seen long-path echoes that come back to me from the opposite azimuth. (The SteppIR bidirectional mode picks them up.) More often, the return bearing is the same as transmitting. I haven't been able to measure the delay time accurately, but it is roughly 2 dit (element) times at 25 wpm (about 50 msec), indicating a 10,000 mile roundtrip.

It seems to be a real effect. I can get rid of it by changing azimuth or using a dummy load.

My question is whether other ops see this and whether it has been written up anywhere in "ham space". These are not the "long delay echoes" that people have claimed to see. The radio science community does run HF radar to study fluctuations in the ionosphere, and this phenomenon is probably well known to them.

The Orion makes a pretty fair radar set, as it turns out.

Note added (1/8/2006): The "echo" appears to be an example of the more general phenomenon called "backscattering" in which the ionosphere returns a certain amount of power back in the direction of the transmitter. See, for example, "Radio Amateur's Guide to the Ionosphere" by Leo F. McNamara (Krieger, 1994). Backscatter ionograms are one method of probing ionospheric conditions. Ionospheric scattering modes (normally in the forward or near-forward direction) are sometimes used for ham DX communications via non-great-circle routes when the great circle route is not open.

[posted to tentec@contesting.com]