On Older Rigs

Recently, I had a QSO with GP0STH, Ron, on Guernsey Island. Nice to have that new country! He gave me an unsolicited "great audio" report. Now, that was interesting...

I had just resuscitated my 30 year old Kenwood TS-520S to see how well the old rig was running. The Orion was sitting quietly on my desk.

The funny thing is that the Orion is well-known for great audio, and my Kenwood and its stock MC-50 microphone is not. But the Kenwood is the one that got that report. And its market value is about 1/15th of the Orion's!

Of course the Orion Rx is a lot better in difficult conditions, but on that day on that band (20 M), the '520 got the credit.

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

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.

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.

Hello - Radio

ARRL's new ham website is up and running at http://hello-radio.org/ .

2005 Freq. Measurement Test Results

I entered my first ARRL Frequency Measurement Test in November, 2005, as predicted in a previous posting.

My results came back recently:

Band	Error (Hz)	ppm Error
160M	1.22	-0.66
80M	0.59	0.15
40M	-0.69	-0.09

On 160M, there was a far stronger signal level than the other bands, but the results are the worst, probably because of mixed propagation paths, unstable ionosphere, etc. On 40M, the signal was so weak I was not sure if I had it at all, amidst all the QRM. Probably this was ground wave propagation.


The full ARRL report is here.

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.

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]

SKN - Straight Key Night 2006

They've been doing it for years, but somehow I didn't participate in "SKN" until Jan. 1, 2006. Straight key night is a kind of ham New Year's celebration sponsored by the ARRL. For 24 hours, beginning at midnight GMT (7 pm EST in the US), this event encourages everyone to work many stations using CW (Morse code) sent by "straight key".

A straight key traditionally is the simple up-and-down telegraph key, well known from the movies. Lately, the definition has been expanded to include mechanical, semiautomatic "bug" type keys like the Vibroplex. Both these keys have largely been replaced by electronic keyers controlled by a key "paddle". An electronic keyer is much easier to use, especially at higher speeds.

Anyway! Straight key night encourages old-fashioned Morse conversations, and it's a lot of fun in a low-key and noncompetitive way.

I had contacts with 12 hams in the course of SKN: KB5IEU, WA7SPY, W6IO, KD5CB, PS8HF, ZS6SIG, AB5VA, WA5ZNU, XE1ELA, W3TMZ, N5KEV, and K8AQM, with time out to host a small New Year's Eve party at our house -- and some sleep.

SKN is old-fashioned, but as I was filling out QSL cards, I came across Leigh WA5ZNU's blog of our contact -- that he had already posted. You can't escape the Web!

Optimal Callsign Lookup Page

If you want a quick and minimal callsign lookup, you could do worse than www.aa6e.net/lookup.html.