Wednesday, December 16, 2009
Hawaii, as you like it.
Sunday, December 06, 2009
Yet another clock program
So I was grumping to myself that my nice, big, cheap Timex digital clock wasn't doing the best job for the ham station. I had modified it for 24 hour time, but the 10 hours digit could only provide a squiggle and not a proper "2" for 20-23 hours. That, and it is physically in the wrong place (away from my computer screen) and it doesn't show civil (local) time along with UTC. I've searched for a good hardware solution with no luck.Then I looked at some of the many Linux clock options out there. None of those was exactly right for me. I wanted digits I could read across the room, but that would fit onto my crowded Linux desktop. Anyway, it's always more fun to use software you build yourself. I pulled out my Python and wxWidgets (wxPython) references and set to it. As with designing and building your own hardware, half the reward is the stuff you learn along the way.
So here is the product. If it looks like it might be useful to you, it should run on any recent Linux system with no hassles. I also checked it on Windows XP and Windows 7 for good measure. It works there, but you will have to download Python and wxPython from the web. (Linux systems like Ubuntu provide these as part of their repository system.) MacOS will likely also support this program.
This is free (as in beer) and open source software, distributed under the GNU General Public License. That means you can download it and modify it to your taste, as long as you are willing to make your improved source available to the community if and when you distribute your new version.
In a future version, it might be worth working on desktop space efficiency. You notice that nearly half the window area is wasted on Gnome's frame decorations and menus. That could be reduced by using "shaped" frames at the cost of complicating the code and creating non-standard window behavior.
Thursday, November 26, 2009
Why Linux/OSS for Amateur Radio?
These issues will directly affect relatively few hams. Many are "appliance operators" when it comes to software, just as for hardware. For them, a proprietary OS may be a good choice because of its familiarity and the huge choice of available software.
We can admire the dedicated hams who build their own stations and who are on the cutting edge of new hardware technologies. It's the same with software. With software becoming increasingly central to amateur radio (in SDR, digital modes, etc.), competence in coding is getting to be just as important as operating a soldering iron.
While you can roll your own software from scratch, it can be far more efficient (and -- as we like it -- cheaper!) to build your code in the OSS "ecosystem", making use of many libraries and tools that are free for the download. OSS really pays off when you give the fruits of your labor back to the community to spur further development.
These are a few of my open source thoughts!
(a comment on a Linux Journal blog)
Wednesday, November 04, 2009
AC plugs around the world
If you've traveled around the world at all, and you're a ham operator, you've surely wondered about all those different AC power plugs. So who has the best? We have a view from the UK here.Naturally, the UK wins! I can sympathize with the safety advantages: fusing in the plug and automatic shutters in the socket. (This is for a "manly" 240 V, you know.) But the authors don't consider a few other questions: cost, size, and weight, for example! Those plugs are heavy, bulky, and expensive. The wall sockets take a lot of area for each power point. Don't even ask about outlet strips or "cube taps".
Monday, October 12, 2009
My New "Boonton" Model 59 GDO
The developer was the well-known engineer Jerry Minter. (See his IEEE.tv interview that prominently shows the Model 59.) His was one of a number of instrumentation companies active in Boonton, N.J. after the War. There was no connection to Hewlett Packard. (An impression I had at one time.)
I used a Model 59 extensively in the 1960's and 70's, but I did not know that it was a classic even then. Now, it's very satisfying to have my own! It is far superior to the Heath GDO and tunnel diode dipper that I have also used. I see one advertised at $75 on E-Bay, but I got mine for about half that.
The grid dip oscillator is a very handy item for generating signals, checking for resonance, and making rough frequency measurements. This one covers the range 2.2 to 420 MHz in 6 bands.
[Click photos for more detailed versions.]
It is necessary to inspect all new equipment here at AA6E. (The unit was in remarkably good condition. It worked the first time and only needed a little cleaning.) This device had wonderful "build quality" -- as we say these days. The important part is the tunable oscillator assembly, which is meant to be hand held. The inner works are all gold plated (!) and very sturdy. A single 955 "Acorn" triode tube is the active element. Lead inductances are kept very low to allow UHF operation.
Dial calibration is meant to be quite good. Each unit's coil set is supposed to be calibrated to work with a specific oscillator head, although my coil set's serial number doesn't match my oscillator. The tuning "feel" is very smooth.
The power supply uses a 5Y3 GT rectifier and an OD3/VR150 voltage regulator tube. The red filaments and the purple regulator discharge, along with the incandescent (!) pilot light, are a treat by themselves. Not shown is the neat wiring harness beneath the power supply chassis.
Now I need to build another RF gadget!
Sunday, October 11, 2009
Nutmeg Hamfest 2009
Note: Click on photos for more detail.
A hamfest always begins with checking out the competition's mobile installations. Relatively few HF installations compared to Dayton.









Friday, September 25, 2009
Commercialization: ARRL Does a Good Thing
The basic points, in my reading: (1) Amateur Radio operators, by FCC regulation and with narrow exceptions, are volunteers and are normally not allowed to communicate when they have a pecuniary interest, for example, on behalf of their employers. (2) Organizations may not use Amateur Radio frequencies when there are alternate licensed (or unlicensed) radio services that can be used, such as the Land Mobile or Commercial Mobile services. (3) Provisions in the FCC regulations suspending some normal rules during time of disaster or in emergency situations do not allow organizations to plan communications on Amateur frequencies without obeying FCC licensing regulations.
The ARRL Board does not cite specific instances of real or planned abuse or exploitation of Amateur frequencies, but we can guess what they might be. An organization wants to assure business continuity by using ham equipment and frequencies, either with or without help from licensed Amateur operators. There might be many variations of this picture, ranging from purely commercial entities to non-profit charitable organizations that want to provide community services, but with in-house paid personnel, with or without licenses. In any case, the nature of the Amateur Radio Service and its frequency allocations would be put in jeopardy by operations that are making an end-run around inconvenient FCC regulations.
The League Board makes a clear and urgent call for Amateurs and Amateur organizations to read and understand the relevant FCC regulations, and to carry the message to all forums where emergency communications services are being planned and coordinated.
Beyond their informative and persuasive arguments about appropriate use of Amateur frequencies, I though the Board's consideration of the roles of the FCC, the Amateur Radio community, and the ARRL itself to be very interesting. We must remind ourselves that Amateur Radio is largely a self-policing enterprise. It is unrealistic and unwise to expect the FCC to specify precisely which uses are acceptable or not acceptable. (Be careful what you ask for!) It is up to each of us to understand the law and the regulations and to develop a consensus of what kinds of operations to support or to oppose.
(Reading between the lines, now.) The scary scenario we want to prevent is having large governmental, non-profit, or for-profit organizations, see how sweet the inexpensive, relatively informal world of Amateur Radio is, as a way to satisfy their urgent needs. In some cases, Amateur groups may be only too willing to accept generous donations of equipment and other support in the name of emergency communications operations. In reality some of these large organizations have a lot of economic and political power and could turn around and actually threaten Amateur Radio spectrum in the future, by co-opting our frequencies in the name of emergency services.
The commercialization issue is just one example, to my mind, of the growing tension between Amateur Radio, which is traditionally shoe-string, informal, improvisational, and local, as against the well resourced, highly structured, and even quasi-military environment of large-scale emergency response organizations and corporations. Good luck to the ARRL, and to us all, in working that one out.
Update: I should explain that I've been a ham for 50+ years, but apart from the odd Field Day, have had little involvement in the emergency communications side of Amateur Radio. (I admire those who do!) I like DX and casual contacts using CW, PSK31, and even SSB. And I do other stuff that you can read about on this blog.
Saturday, September 05, 2009
Amateur Radio vs HPC & OSS
Lately, I've been wondering what aspects of Amateur Radio would benefit from high performance computing technology. This is prompted by my latest PC - built around an Intel Core i7 processor with 6 GB of RAM. This CPU has 4 cores and 8 logical (hyperthreaded) processors. The benchmark results are very nice: 20,500 Whetstone MIPS (floating) and 45,200 Dhrystone MIPS (scalar) across 8 simultaneous threads. [BOINC's built-in benchmarking - not to be taken at face value!] In addition, we have graphics processors (GPUs) that can be programmed with CUDA, OpenCL, and similar methods.
Some general areas that occur to me:
- Digital Signal Processing (Audio-ish) - This is the technology behind much of today's Software-Defined Radio (SDR). A significant amount of processing is required for mixing, modulating, and demodulating signals. Dynamic spectral displays are useful. However, the actual amount of horsepower required for typical amateur applications is fairly limited. In most cases, the bandwidth of interest is less than 128 kHz (the range of high-end audio cards for band monitoring displays) and very often less than 3 kHz - the maximum audio bandpass of most communications transceivers. As long as we are working with audio-type signals - PSK31, Olivia, RTTY, and SSB, we are not likely to tax the latest CPUs. You can use more power if you want to listen to many channels at once, but even so...
- DSP (Video) - Modern HDTV signals require a lot of processing. In production work, this would mostly be done in special-purpose processors (I think), but amateurs might prefer to operate with commodity PC and GPU hardware. I am not aware of amateur HDTV work for over the air transmission, but there may well be some. My initial look at HDTV (and DTV) was discouraging. The sheer numerology of options is overwhelming -- although of course, you may only need one mode for ham work.
- DSP (Video 3D) - How about ham communications through 3D immersive environments? Four-pi visual fields, multichannel sound: you could get the gamers into that! (But why ham radio? Why not FIOS-type connections? We can offer off-grid operation and mobility away from cell towers!)
- Radio Science - Propagation Analysis and Prediction through detailed atmospheric modeling, ray tracing, etc. This could be extended to real-time monitoring of the HF bands at points around the world, and trying to build up a real-time DX prediction service.
- Exotic wideband signalling. Using microwave bands and pursuing highest bandwidths. Would this be more a question of very fast D/A conversion and I/O more than general purpose computing?
There must be more areas for HPC in Amateur Radio. As a long-time HF operator, I'd like to be able to translate CPU power into greater sensitivity and interference rejection. We can certainly consider computationally intensive modulation and demodulation schemes, but it's not clear what returns are available in a channel's SNR given the practical limits on transmitter power, modulation bandwidth, antennas, etc. The ionosphere degrades the signal so that frequency resolution below about 1 Hz or so is not going to be very productive. How can a "supercomputer" overcome that?
Ideas, anyone?
[This is cross-posted with my SourceForge blog: http://sourceforge.net/userapps/wordpress/aa6e/. Why do I have an SF blog? For topics relating to open source software, to see what WordPress is all about? Something like that!]
