
After a little discussion with Jack Smith about the inner workings of his Z100 Tuning Aid (last post), one thing led to another.
The result is another little Python utility that does much of what the Z100 does, but in software under Linux.
The scoop and download are available here.
Tuesday, January 29, 2008
Z100 -> P100!
Posted by
Martin Ewing
at
1/29/2008 11:52:00 AM
1 comments
Thursday, January 24, 2008
A Z100 Arrives
This is the Z100 "Tuning Aid" from Clifton Laboratories, as described by Jack Smith K8ZOA in the January/February, 2008 issue of QEX. I bought the kit and put it together as sort of a post-Christmas present to myself.
The Z100 is a pseudo-spectrum analyzer, using a simple zero-crossing detection and averaging algorithm as I understand it. It is intended to help "zero beat" a received CW or RTTY signal so that you can respond on the same frequency within a few 10s of Hz. (It's not zero beating really. With current rigs, you want to tune to a certain offset "spot" audio frequency that corresponds to your transmitter's output.)
A few notes on the Z100 so far
- Assembly was straightforward until it came to making the LED bar-graph indicator, which you must construct out of individual LEDs and spacers. Getting a neat result is tricky. I judge I managed it fairly well on the first try, but you need to read the instructions carefully. A number of hams have contributed handy alternative techniques that Jack includes in his write-up.
- Assembly of the board into the case, along with a clear lens and an optical filter film is the next tricky part. All in all the mechanical work with the LEDs and the case seemed overly difficult. It would have been very helpful if the filter film could be dispensed with -- e.g., if a neutral density Lucite lens could have been used.
- Operation (for an hour so far!): The Z100 is easy to connect and use. It does require reasonably strong CW signal (i.e. fair SNR) to make the CW note show up clearly out of the noise. I seem to work weak stations quite a lot, and the tuning aid may be difficult to use for them. A more intelligent algorithm would be able to pick a coherent signal out of the noise much better, but that would be beyond the capability of the simple PIC processor, I reckon. It would boost this kit well out of the $60 price category.
- Jack is to be commended for producing a very "open source" project. The PIC code is available for study and modification, and the QEX article and product documentation gives full design details. (A perfectionist might say that a true open source project should also distribute Gerber-type files for the PCB design, but that would be a quibble!)
Posted by
Martin Ewing
at
1/24/2008 03:49:00 PM
1 comments
Topics: accessories, CW, digimodes
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.
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.
Posted by
Martin Ewing
at
7/19/2006 11:48:00 AM
0
comments
Monday, January 02, 2006
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!
Posted by
Martin Ewing
at
1/02/2006 12:27:00 AM
1 comments
Saturday, July 23, 2005
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!
Posted by
Martin Ewing
at
7/23/2005 11:32:00 AM
1 comments
Topics: CW
Wednesday, April 27, 2005
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.
Posted by
Martin Ewing
at
4/27/2005 12:44:00 PM
0
comments
Topics: CW
