Orion Frequency Calibration

The Ten-Tec Orion Transceiver is specified for frequency accuracy of + or - 3 ppm over the temperature range 0 - 50 C. That amounts to +/- 30 Hz at 10 MHz, or nearly +/- 90 Hz in the 10 meter band. In an SSB QSO, an error of 50 Hz is pretty noticeable. In a PSK31 QSO, a whole QSO fits into a 30 Hz band, so such an error could be quite serious. Fortunately, we rarely need to set our VFOs with such accuracy. We need precision, but we can just tune for best reception. It does matter near a band edge, but it would be unusual to have to work within 50 Hz of an edge.

The most likely case where good accuracy can help in the HF bands is when we operate in roundtable mode on SSB. Frequently, a group sets up on a specific frequency, like 3813.000 kHz. If we don't have good accuracy, and if we don't all tune up carefully on one station, we may have to use the RIT every time a different person is speaking. The better our absolute setting accuracy, the less trouble we will have in net operations.

So, how well can we do with a little effort on the Orion? I developed a technique for measuring my frequency error against WWV. (See note below.) My zero beat setting before adjustment was typically about 9.999987 MHz after warmup, 13 Hz low, corresponding to the master oscillator running high by about 1.3 ppm, well within Ten-Tec's spec.

The master oscillator in the Orion is a temperature-compensated crystal oscillator (TCXO) running at 44.55 MHz. It is a Siward series TXO32, apparently, with a mechanical fine adjustment. The following is my record of how I adjusted my oscillator.


First, remove the bottom cover of the Orion. There are 4 screws on the sides and many little Torx head screws around the rear lip. The top cover can stay in place. After the cover comes off, you are treated to the spacious glory of the Orion underchassis. The TCXO (circled) is on the A10 synthesizer board at the top.

This is the temperature compensated crystal oscillator (TCXO)

Here we do the actual adjustment. Note the pickup loop for the Icom R-8500 receiver to monitor 44.55 MHz. Fortunately, the TCXO does not require a non-metallic adjustment tool. An ordinary jeweler's screwdriver works fine. The adjustment feels a little coarse if you are trying for exact zerobeat with WWV -- i.e., sub-1 Hz beat. Keep in mind that 1 Hz at 15 MHz is .07 ppm, much finer than the specified oscillator accuracy. Because the oscillator temperature will be substantially less than normal with the case open, you do not want to zerobeat WWV. (See text below.)

The Icom R-8500 communications receiver was useful to monitor changes to the TCXO. It has its own internal TCXO reference. Such a receiver is not required for the Orion adjustment, but it is a help if available.

At the end, we put it all back together and give ourselves a professional-looking (?) calibration sticker.

Procedure
Before attempting the adjustment, it is useful to study the warmup characteristic of the Orion TCXO by zero-beating WWV over several hours, as the operating temperature stabilizes. Room ambient temperature was about 78-80 F. Naturally, you need to do this with the transceiver in its operating position with the covers on. Here is a typical warmup run monitoring WWV on 15 MHz.

Time (min)	Frequency	Error (ppm)
0	14.999 980	1.3
11	15.000 000	0.0
38	14.999 995	0.3
73	14.999 989	0.7
85	14.999 986	0.9
101	14.999 984	1.0
137	14.999 983	1.1
177	14.999 980	1.3

It would have been interesting to measure temperature along with time, but I did not have a temperature probe. (The A10 board runs pretty hot to the touch, and it is in a poorly ventilated area under the chassis. I would estimate the operating temperature is around 50 C.)

After running the warm-up curve, we note that the TCXO ends up 1.3 ppm high. The dial reading is 1.3 ppm or 20 Hz low. Therefore, we want to trim the TCXO so the dial reading increases by 20 Hz. That should bring the TCXO very close after warmup.

Another issue is which WWV frequency to use: 2.5, 5, 10, 15, or 20 MHz. Other things being equal, the highest frequency gives the best setting precision. One Hz at 20 MHz is .05 ppm. Propagation is a concern, however. We need a strong and steady signal. If the signal has much QSB (fading), it is likely to have a lot of frequency dispersion. You won't be able to find a steady zerobeat. You may want to avoid periods of significant solar or geomagnetic activity for the same reason. (Check http://www.n3kl.org/sun/noaa.html for current data.) For the most part, for my path the 15 MHz transmission worked best. I compared my results at 15 MHz with 10 MHz as a check. They were in good agreement.

Conclusions
The Orion's TCXO can be adjusted to within a few times 0.1 ppm, and it will stay put if the transceiver's operating temperature is stable. Crystal aging is a factor, however, so the calibration may have to be repeated periodically.

---------------

How to Zero Beat the Orion with WWV.
I have tried two methods of finding a precise zerobeat between the Orion's effective local oscillator frequency and a reference frequency transmission.

1. Zerobeat using CW Spot tone. (easiest for me) Set up for normal CW reception with say 300 Hz bandwidth. Hold down the Spot button and tune until you hear the beat note when the signal frequency equals the spot tone. Again, you should find the zerobeat within +/- 1 Hz.
2. Zerobeat on noise. If the IF passband offset (PBT) is set for say -100 Hz and the bandwidth is 200-300 Hz, set the AGC to "fast" and the mode to USB or LSB. The Rx audio deemphasis should be zero or positive. The tuning step needs to be 1 Hz. Find the beat note and adjust slowly for lower and lower audio tones. After the tone becomes sub audible (about 60 Hz depending on your speaker), carefully tune to zero. When you are within one or two Hz of zero beat, you should hear the receiver noise fluctuate up and down with the beat. (This is the effect of AGC.) It should be possible to locate the zerobeat to +/- 1 Hz. This method requires a fairly strong reference level.

--------
Note added (1/8/2006): An alternative procedure is given by K6SE at http://www.n5na.net/download/Orion_Freq_Calibration.pdf .

Morse Code, we hardly knew ye.

The handwriting has been on the wall for some time. First, the International Telecommunications Union (ITU) lifted the Morse Code requirement for ham licenses capable of international communications (mainly in the HF "shortwave" bands). Then many national communications agencies began removing the Morse component of radio amateur license requirements. Now, after some delay, the U.S. Federal Communications Commission (FCC) is proposing the same for the U.S.

Morse still has an avid following among ham operators. (I just joined the FISTS organization myself.) The Morse requirement is entwined with the long history of amateur radio. Recent changes to "water down" the license qualifications have been controversial. Often the arguments are of the type "When I was a boy..., men were men...".

Meanwhile the world has moved on. Demographically, the young experimenters who once sustained the hobby have moved on to video gaming and the Internet. The number of licensees seems to have peaked around 600,000 and has started a slow decline. (Removing the Morse barrier may give the numbers a boost.)

Technically, the operating modes available to hams have exploded. Beside traditional Morse and voice, there are now many computer-assisted options: keyboard-to-keyboard (many flavors), file transfers, digital voice and video, special modes for weak and bursty channels (moonbounce, meteor scatter), and more. Fortunately, we do not have to prove competence in each of these to qualify for a license.

Morse code is an anachronism, but we like our anachronisms. Listen to the low end of most HF amateur bands and you will find hams "pounding brass". Join in!

Grounds & Lightning, more

The ground system (described earlier) is now "complete". The shack's Single Point Ground (SPG) panel is now connected to the copper waterpipe entrance via ~30 ft of 1.5-inch copper strap. The attachment is adjacent to the AC service entrance ground clamp. It would be better to go immediately out the window by the SPG to "ground" -- only a few feet away, except that that ground is dry (under a stone walkway) and there is only 4 or 5 inches of soil on top of granite ledge.

The next improvement in this system, in my opinion, would be to lay a perimeter ground loop around the house, attached to a large grid that extends over the ledge under the soil. A lot of work for a not super-high-risk area.

This morning at 5 AM, we had the first test of the system as a lightning rich storm front passed through. There were apparently some hits in the neighborhood, but all equipment survived here.

We are left with an S9-plus source of HF noise, however. It sounds like power line arcing, and it's bad over at least 40-12 meters. The good news (?) is that it's not in our house. The beam indicates a strong maximum at about 10 degrees azimuth, which is the direction that power comes in in the neighborhood.

Your comments are appreciated!

73, Martin

June 29 note: The intense RFI disappeared by evening. I had predicted to the XYL that it might just "burn itself out". I did a little neighborhood sniffing and found the noise was coming from a nearby house. By its sound (very spikey 60 Hz related), it could have been a burned-out diode in a battery charger, caused by a lightning surge. (One neighbor reported their phones went out of service.) I saw a smaller version of this when the 12-volt switcher "brick" for my computer's LCD display went bad. Lots of RFI, and the brick got quite hot to the touch.

So the RFI disappeared, I did not have to complain to anyone, and the neighbor's house did not burn down.

By the way, this was the first time I got to test the Orion's noise blanker function. (At this QTH, there is rarely much impulse noise.) The hardware NB was quite good, up to 5 S-units suppression on 20 meters. The DSP NB helped some, but not nearly so much.

W1YU - Signs of Life at Yale

As an historic college radio club looking for a new way, the Yale Amateur Radio Club - W1YU - is reinventing itself. We are using email and the web to bring together a community of faculty, staff, students, alumni, and retirees.

A first step is to institute a "roaming club station", similar to the FISTS rotating callsign KN0WCW. If you are related to Yale and a ham, you can have the W1YU callsign for a time.

See the new club website: www.yale.edu/w1yu .

Free Software and Ham Radio: The Hamlib Project

A great feature of Amateur Radio is the range of activities you can join in. Everyone can find a home with some operating style or technology work. Some of us combine on the air work with computer programming.

I’ve found a particular corner of ham radio called the Hamlib project, initiated in 2000 by Frank Singleton (VK3FCS/KM5WS) and Stéphane Fillod (F8CFE) and supported by dozens of hams around the world. The Ham Radio Control Libraries are intended “to provide a consistent interface for programmers wanting to incorporate radio control in their programs.” This project is an example of “free and open source software”, developed by a large group of people who volunteer their time. You’ve heard of Linux and the Mozilla and FireFox browsers? They were created the same way.

You may know about “software defined radio” (SDR). That’s not what Hamlib does. Hamlib manages the control functions of radios, including DSP and SDR rigs, but it does not do signal processing itself. Hamlib is largely developed in the C language under Linux, but it is adaptible to other operating systems (MacOS, Windows) and languages (C++, Python, Perl and others).

If you’re a programmer using Hamlib, you can write applications to work with many current and older radio devices that permit computer control. This is a big benefit, because you can spread your time investment over the greatest number of potential users. Most radio control packages today are written for specific devices (“rigs”), but the potential “market” for software for one radio model is always limited. Even hams who write “free” software think about market share!

The Hamlib project is ambitious, aiming to support over 200 rigs and variations, ranging from scanners and shortwave receivers to exotic computer-based DSP transceivers and some antenna rotators. The strategy (Figure 1) is to provide a library that adapts many different radios to a higher-level application program. If you are a typical ham who is not a programmer, you can download a software application package that is built “on top” of Hamlib. A number of Linux applications are already available for digital mode support, logging, etc. Check the Hamlib web site at http://hamlib.sourceforge.net .



Figure 1: Hamlib is the “glue” that connects applications programs to ham rigs.

Hamlib is tackling a big problem. How do you provide for scanners with a thousand memory channels, priority sampling, and so on in the same program with multi-band VHF transceivers and computer-based DSP HF radios?

The problem is not as bad as it might be, since rigs tend to fall into categories (receivers, VHF transceivers, HF transceivers, scanners, etc.) and into product families that share similar interface protocols (Icom, Ten-Tec, Yaesu, Kenwood, etc.) It is also possible to define a useful subset of each rig's functions -- at minimum. frequency, mode, and transmit/receive. For many rigs and applications, such as QSO logging, that is sufficient.

If you want to write a ham application program to talk to a radio, you have an interesting choice: Should you aim for the best possible interface for a particular rig on a particular operating system? Support a particular rig on multiple operating systems? Support many rigs, as Hamlib does, on a variety of operating systems? It's a trade-off of man-hours, features, and desired market share.

[A shortened version of this article is scheduled for publication as a "Stray" in QST.]

Why I'd like a digital IF output on my Orion

What could you do with a digital IF output from the Orion transceiver connected to your PC? I have a few ideas. Maybe you can add more.

• Custom IF DSP filters in your PC - like an optimized RTTY filter. (The Sharc DSPs are efficient for DSP, but modern PCs should be plenty fast enough to process a 20 kHz band.)
• Support interesting modulation modes (ISB, synchronous AM, DRM, PSK31, and all the other strange modes). Avoid the compromises of audio soundcard interfaces.
• Detect multiple data streams simultaneously
• Record your IF for later playback and analysis
• Real time spectral display.

If you had a digital IF input for Tx, you could generate interesting modulations in your PC, multiple audio/data streams (ISB or multiple SSB, digital audio) - FCC permitting.

The programmers among us would be able to enhance Orion's "software defined radio". Eventually there will be killer signal software for general use on everyone's PC.

What is CW?

There are some interesting threads on the tentec@contesting.com list about CW. The question came up "What is CW?", both as to technology (how is it generated) and regulation (how is it defined.) Here are my 2 cents on the subject.

(If you're new to ham radio, CW stands for "continuous wave". In traditional Morse radiotelegraphy, your transmitter sends a steady wave when your key is down and no signal when your key is up.)

Having nothing better to do, I went to the FCC website to read up on Part 97 regulations and what they say about CW. The relevant sections are 97.3 which refer back to 2.201 and 2.202. Some excerpts are at the end. Classical amateur CW might be 100HA1A, specifying 100 Hz bandwidth, or simply A1A. The ARRL FCC Rule Book has some useful material, too.

It seems that the FCC is interested in the signal that shows up on the air and not how it is generated. Fair enough. Normal amateur CW is A1A, I believe. Some generation methods (like audio tones into a not-so-good SSB rig) are worse than others. FCC requires signal purity to observe good engineering practices, or words to that effect, and that may rule out the KWM-1 technique nowadays. The DSP method (e.g., Ten-Tec Orion) can be as perfect as you're willing to pay for.

As the Rule Book (8th ed.) explains, it would be possible to narrow the "100 Hz" DSB spectrum of an A1A signal by eliminating one sideband (50 Hz) and suppressing the carrier. (However you make it, CW does have a carrier and sidebands just like a voice signal.*) I wonder if anyone has ever done it, and whether a half-width carrier-less CW (or psk31?) signal would be decodeable after HF propagation. You'd need really tight frequency and passband control.
--------
*A carrier? What about between characters? Yes, mathematically the carrier is still there -- even after you turn your rig off. Of course, there are also very low freq sidebands that conveniently cancel out the voltage... So your rig had better be very very linear or it won't be safe to shut off the power! Don't lose sleep over it.

A Little More Python for the Orion

I've posted a nifty little tester for the Ten-Tec Orion at my main website. It lets you send & receive arbitrary ASCII strings to the serial port. It's in Python, and Python is supported on many OS platforms. I have recently verified that the software will run under Windows, using Python for Windows, win32all, and pyserial for Windows. (The only module missing in Windows/Python is a "curses" package for my original octl program.)

Work continues on the Hamlib driver for the Orion. Latest: TT designed the antenna switching matrix "inside out". You select the transmitter/receiver(s) that want to be attached to a particular antenna, instead of the other way round. Oh well, we can fix it in software. We recently declared the driver to be "beta quality". Anyone care to prove me wrong?