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 .
Tuesday, May 31, 2005
Friday, May 13, 2005
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.]
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.]
Friday, May 06, 2005
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.
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.
- 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.
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.
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.
(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.
Thursday, April 14, 2005
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?
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?
Tuesday, March 29, 2005
Ten-Tec Orion S-meter & Hamlib
We have been making some progress with the Ten-Tec Orion backend software in the "Hamlib" package, an open-source project to provide a device-independent programming interface for amateur radio equipment in the Linux/POSIX world.
Here's a tid-bit you won't find everywhere: the Orion S-meter calibration curve.
(Literary event: I just defined "S meter" in the Wikipedia! See my article.)
The Orion has a couple of peculiarities when measuring power. The minimum reading (on my unit) is about S 1.5 on all bands when looking at a dummy load. What does that mean? If S9 = 50 µV, then S1.5 is 6 dB x 7.5 S-units or 46 dB down in power = 2.5 x 10-5. The voltage ratio is the square root of power, or about 5 x 10-3. So the equivalent RF voltage level is 50 x 5 x 10-3 = 0.25 µV. The Orion's sensitivity spec (main receiver) is "< 0.18 µV" says that the receiver's internal noise will be about this level, which is consistent with the meter reading. In other words, Ten-tec seems to have this right.
(On the other hand, the tried and true RST system says that S1 means "Faint signals barely perceptible". That's an argument for using 5 dB per S-unit, as some have defined it, at least with our current generation of receivers.)
The other feature of note on the S-meter is the behavior at very high signal levels. As you can see from the calibration table above, the raw S-meter units are spread out roughly 8 units per 10 dB. However, the meter reading is highly quantized. You only see values of S9+48 and S9+65, nothing in between. This indicates that the software computation of received power has a quantization problem. Of course, it's hard to complain too much, because such power levels are almost never seen in real life. (If they are, better switch in some attenuation!)
Here's a tid-bit you won't find everywhere: the Orion S-meter calibration curve.
#define TT565_STR_CAL { 15, {
{ 10, -45 }, /* S 1.5 min meter indication */
{ 13, -42 },
{ 18, -36 },
{ 22, -30 },
{ 27, -24 },
{ 30, -18 },
{ 34, -12 },
{ 38, -6 },
{ 43, 0 }, /* S9 */
{ 48, 10 },
{ 55, 20 },
{ 62, 30 },
{ 70, 40 },
{ 78, 48 }, /* severe dsp quantization error */
{ 101, 65 }, /* at high end of scale */
} }
The first column is the Orion's response to the "?S" command in computer units. The second column is indicated decibels (dB) as read on the actual S-meter.(Literary event: I just defined "S meter" in the Wikipedia! See my article.)
The Orion has a couple of peculiarities when measuring power. The minimum reading (on my unit) is about S 1.5 on all bands when looking at a dummy load. What does that mean? If S9 = 50 µV, then S1.5 is 6 dB x 7.5 S-units or 46 dB down in power = 2.5 x 10-5. The voltage ratio is the square root of power, or about 5 x 10-3. So the equivalent RF voltage level is 50 x 5 x 10-3 = 0.25 µV. The Orion's sensitivity spec (main receiver) is "< 0.18 µV" says that the receiver's internal noise will be about this level, which is consistent with the meter reading. In other words, Ten-tec seems to have this right.
(On the other hand, the tried and true RST system says that S1 means "Faint signals barely perceptible". That's an argument for using 5 dB per S-unit, as some have defined it, at least with our current generation of receivers.)
The other feature of note on the S-meter is the behavior at very high signal levels. As you can see from the calibration table above, the raw S-meter units are spread out roughly 8 units per 10 dB. However, the meter reading is highly quantized. You only see values of S9+48 and S9+65, nothing in between. This indicates that the software computation of received power has a quantization problem. Of course, it's hard to complain too much, because such power levels are almost never seen in real life. (If they are, better switch in some attenuation!)
Monday, March 21, 2005
Toward a Provisional Philosophy of Grounding
About grounding. There's so much information and advice out there that is sometimes contradictory. Partly this is what it means to be a radio amateur. Some folks have some credentials, but it's hard to know how to interpret what you read.
My background is in Physics, Radioastronomy, EE, and IT. So I have some textbook knowledge of electricity & magnetism and some practical experience with radio telescope systems. I would not claim to know much about lightning protection, but I know enough to be skeptical.
The basic problem is that few if any hams are able to test their grounding systems. Some people survive some dramatic "events", and their equipment sometimes does and does not. But in most cases there's no statistical significance. The commercial tower people probably know a lot, but they don't try to integrate RF systems into their residences. A few hams in high-risk locations survive multiple strikes every year. They're the ones to listen to.
There are some general principals that can guide us. Mainly, you want to provide a low impedance path to ground from "up high" that will not pass through you, your house, or your equipment. In a residential environment, there are always compromises. The ideal ham shack would be a windowless metal building on its own pad with a carefully laid out grounding grid and protection on every wire coming in and out. (Like a cell phone hut.) Failing that, it is probably a good idea to have as many ground rods out there covering as much territory as possible. If you don't "bond" your ham ground to your AC ground (and other lightning protection grounds, if any), you run the risk that there will be high potential differences between them during an event. What would happen if your AC plugs (all 3 wires) suddenly were at 20 kV relative to your equipment?
My local SPG system is an attempt to establish a locally bonded system that will forestall large potentials from occuring between anything near my ham gear. I will try to connect it to the AC entrance ground and a new ground rod system, difficult as that is on a granite ledge.
I don't have confidence (in a statistical sense) that this will work against the likely threats. It was fun to build. At least, it will improve the RF and AC safety grounding by a bit.
Read below to see the project at my QTH.
My background is in Physics, Radioastronomy, EE, and IT. So I have some textbook knowledge of electricity & magnetism and some practical experience with radio telescope systems. I would not claim to know much about lightning protection, but I know enough to be skeptical.
The basic problem is that few if any hams are able to test their grounding systems. Some people survive some dramatic "events", and their equipment sometimes does and does not. But in most cases there's no statistical significance. The commercial tower people probably know a lot, but they don't try to integrate RF systems into their residences. A few hams in high-risk locations survive multiple strikes every year. They're the ones to listen to.
There are some general principals that can guide us. Mainly, you want to provide a low impedance path to ground from "up high" that will not pass through you, your house, or your equipment. In a residential environment, there are always compromises. The ideal ham shack would be a windowless metal building on its own pad with a carefully laid out grounding grid and protection on every wire coming in and out. (Like a cell phone hut.) Failing that, it is probably a good idea to have as many ground rods out there covering as much territory as possible. If you don't "bond" your ham ground to your AC ground (and other lightning protection grounds, if any), you run the risk that there will be high potential differences between them during an event. What would happen if your AC plugs (all 3 wires) suddenly were at 20 kV relative to your equipment?
My local SPG system is an attempt to establish a locally bonded system that will forestall large potentials from occuring between anything near my ham gear. I will try to connect it to the AC entrance ground and a new ground rod system, difficult as that is on a granite ledge.
I don't have confidence (in a statistical sense) that this will work against the likely threats. It was fun to build. At least, it will improve the RF and AC safety grounding by a bit.
Read below to see the project at my QTH.
Ham blogging
After working with web sites for quite a while, I am just easing into the blogging world. WA1LOU had an ARRL Web Article (June, 2004), but it took a while to bubble up to my keyboard.
I did a search recently and turned up a number of interesting sites. See my links at the right. There's a lot of room for growth here!
From an email to Dan, KB6NU:
I did a search recently and turned up a number of interesting sites. See my links at the right. There's a lot of room for growth here!
From an email to Dan, KB6NU:
... Interesting what you come up with on http://www.globeofblogs.com/ when you look at their "amateur radio" category. I did register there, and now you can find me among the SWLs, podcasters, and what-not...
This is really cutting edge stuff, I have to say -- ham blogging. Ham
radio, for me, has morphed into 10% on-air and 60% Internet, with maybe 30% non-Internet reading and building. (I've been retired for a couple of years.)
Ham radio as a literary form! Unfortunately, [a lot] of hams can't relate to that. I recently looked at QST's guide for authors. Their advice about avoiding high falutin' language is quite charming. Or maybe I could find another adjective.
Subscribe to:
Posts (Atom)