Thursday, November 26, 2009

Why Linux/OSS for Amateur Radio?

How to explain to a non-computer-geek ham what Open Source Software and Linux are all about? OSS and Linux are important to software users the same way a good repair manual and schematics are important to hams. Not every ham knows what to do with schematics, but those who are inclined to open up, understand, repair, and modify their equipment certainly do. Without being able to see what's inside and what connects to what, there is very little you can do. That's exactly why you need to be able to access and work with source code when it comes to software.

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

Here is my big acquisition from the Nutmeg Hamfest this weekend. It is the classic Measurements Corp. Model 59 Megacycle Meter. Some of us would know it as the "Boonton Grid Dip Oscillator." From what I've been reading, a variant of this unit was first produced in World War II. The manual, available here and here on the Internet, bears a 1947 date. The company was sold to Edison in 1953, so this unit was probably produced in the early 1950's. (The meter/power supply unit is serial #750, the oscillator head is #695, the coil set is #734.)

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

The Connecticut Nutmeg Hamfest for 2009 went on in glorious fall weather on October 11.
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.


Always enter by way of the flea market to see what's up. People noted that the larger stores and manufacturers were absent this year. There were still a lot of "mom and pop" flea market vendors.


This was the ARRL Connecticut Convention. Left, our Director Tom Frenaye, K1KI. Right, Section Manager Betsey Doane, K1EIC.


A small, but engaged audience for the League Forum.


Joel Hallas, W1ZR, gave a popular talk on multiband antennas. Guess which favorite antennas really don't work very well on the HF bands!

Another rapt audience.


The flea market had some beautiful nostalgic equipment on display. No, it wasn't selling very fast, but it was nice to look at and reminisce. I got a Boonton grid dip meter, just like the one I used 35 years ago!


The Shore Point club (West Haven) had its very snazzy emergency communications trailer on display. It doesn't look like it's worked through many disasters yet!


The Shore Point trailer command desk. Two people, five microphones, and then some.



I thought this was the highlight of the show. It is W1RT's HF - 10 GHz hill-topping van. An amazing collection of gear, all oriented to VHF, UHF, and microwave contesting.


Overall view of the vehicle area. There was also a converted ambulance from the Danbury group.

I didn't know they gave license plates for Unix veterans, but here is one I found:

Friday, September 25, 2009

Commercialization: ARRL Does a Good Thing

Today, the ARRL Board of Directors released fascinating guidelines on the "Commercialization of Amateur Radio: The Rules, The Risks, The Issues". This paper results from the apparent growing problem of some for-profit or non-profit organizations looking to Amateur Radio frequencies and equipment as cheap solutions for their disaster communications needs, without very much regard for the FCC regulations or the culture or history of Amateur Radio.

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!]

Friday, August 28, 2009

Orion Surgery

My Ten-Tec Orion transceiver was 5 years old in February. It's getting to be an old timer -- in computer years, at least. It needed a few chores done.
  1. The LCD panel was flickering. Internet scuttlebutt says this may be because of impending failure of filter capacitors that were undersize (in terms of ripple current handling).
  2. With the current version 2.xx firmware, the LCD contrast is close to zero after a hardware reset. This can be a serious problem, depending on room temperature. Contrast is normally set via a menu adjustment -- that requires you to navigate through the LCD display. The display could be so faint that you couldn't make the adjustment. There is an internal bias control that should fix this.
  3. Finally, I have been seeing the "RIT freeze" problem that others have noted. At times, the RIT control loses the ability to make any adjustments. Many people have reported this problem, but the cause and cure have not been well understood. It seems that you can fix it temporarily by grabbing the RIT/XIT encoder control and twisting hard in odd directions -- as if there were a bad solder joint on the PC board. A recent report suggests the trouble is actually with one of the board-to-board connectors making unreliable contact.
All the above have been discussed on the helpful Ten-Tec reflector, which I recommend to other Orion users. I have been saving up these problems for some time now. Hopefully, I only have to disassemble the Orion once!

Making a long story short, I pulled the rig out of my operating position, unplugging many cables, unscrewed many screws, and finally spread out the works on my bench. The RIT fix requires disassembling the front panel and the LCD/computer board. That's a fairly big operation, particularly since a wrong move with a tool could lead to a very costly repair job.

I located and replaced 3 electrolytic capacitors on the A9 board with higher voltage, low ESR units, per the helpful analysis of N6IE. Soldering was tricky, to prevent inadvertent short circuits and to get enough heat into the ground connections, which were not thermally isolated from the big ground planes on either side of the board. (That could have been avoided by a better PCB layout!) OK. That's problem #1 done.

The email instructions say that to solve #3, you need to look for bent or misaligned connecting pins on the computer / LCD board. I looked very carefully, but saw no misalignment or other problem. Still, it's possible there was some oxidation or dirt. I cleaned the pins and the sockets as best I could. So problem #3 might be resolved.

The LCD bias issue (#2) turns out to be easy. There is a control on the LCD/computer board that sets the default bias for the display. You just adjust it for a good display with the LCD menu set at the default 50% level (and of course with the power on and the rig having a chance to warm up).

Accomplishing all this, I reassembled the Orion and put back all those screws, and put the rig back in the operating position. Everything appeared to work, except no transmit power. Oops! There are a lot of reasons why this could happen. Fortunately, I did not smell smoke, and that eliminated some of the more expensive possibilities. Still, I'm not sure how much bench testing and repair I would be able to do, if this turned out to be a non-trivial problem. Thinking of where that shipping box might be, and how much Ten-Tec charges...

So, what did I really do in that repair process? I changed out the capacitors, true, but the fact that everything works in receive mode indicates that the power board was probably working. The other thing I did was to unplug many internal cables, disassemble the LCD boards, and reassemble. There could be a loose connection or a misplaced cable.

The problem was "fixed" by opening up the box all the way again, and carefully reinstalling all the cables and screws. We have transmit power for now. I hope it stays that way!

The triple repair job is done. The LCD is behaving much better than before, and at least for now, the RIT/XIT controls work smoothly.

One thing I hadn't counted on was the trouble of reconnecting my ratsnest of cables to the Orion. I have a linear, a transverter, computer audio and controls, and other gadgets that need to be connected. All these just got hooked up over several years, and of course I had nothing documented on paper. Figuring out how to reconnect took a while, but it should be better next time. Now the cables have labels on them. Documentation is still pending...

Friday, August 21, 2009

Atomic Disintegration

My new, humble computer based on Intel's Atom CPU was a great little project at a low cost. It benchmarked at about half the performance of my older Athlon XP 2000+ on a per-thread basis, and it provided two hyperthread "processors" for Linux to use. All for about $64 for the board and CPU. (And it is 64-bit capable, but the value of a 64-bit OS is unclear in such a small system.)

Then, for larks, I set it up to run as a member of my World Community Grid effort. That had it running two threads for 24 hours a day. This was somewhat pointless, given that the new Intel Core i7 system is so much more powerful*, but it did manage to churn out some work-units for the Cause.

All was well for about 4 days. Then ping!, the Atom froze. I could reboot into BIOS sometimes, but couldn't load Linux or even memtest86+. An actual hardware failure -- I haven't seen many of these in recent years.

Over a period of days, I got more acquainted with my UPS driver, as I tried substituting various parts. Suspecting the hard drive or CD/DVD drive (old IDE technology). Tried a substitute 1 GB DDR2 RAM. No help.

So the fault was either in the Intel D945GCLF motherboard or the power supply. The motherboard has about 10 million times more transistors, so that seemed the likely culprit.

Using Amazon.com's amazingly efficient returns/exchange process, I had a new mobo in quick order, and all now seems well.

Do I dare run the WCG application any more?

As to ham radio, this system is my logging and digital modes computer for AA6E. We were dead in the water. I could have fallen back to my mic or key and used paper logging, but I wasn't quite that desperate!

--
* Both in absolute (45,232 MIPS vs 3,060 MIPS) and in power-specific terms (302 MIPS/W vs 64 MIPS/W).