AmateurRadio.com

One of the things at the back of my mind when I was writing that the magic of ham radio wasn’t in high technology was the feeling that anyone who got into the hobby out of a mania for high-tech toys was soon likely to be disappointed. I’ve seen it happen when people who are new to the hobby and don’t yet know much about it get an enthusiasm for APRS or Echolink. They get disappointed that the network coverage is patchy or nonexistent compared to cellphone coverage because they don’t realize that it depends on hams to provide the infrastructure and where there are few hams – or none interested in these particular aspects of the hobby – there are no repeaters and no gateways.

I’ve seen the same people criticize the latest VX-8, TH-D72 and Icom D-Star radios as being overpriced and unimpressive. They don’t like the geeky “walkie talkie” look or the plain 1990s LCD display. They can’t believe that APRS radios don’t support predictive text entry like the cheapest mobile has for more than a decade. And why can’t they have a colour screen and a scrolling map display?

It’s easy to dismiss these criticisms as coming from people who don’t understand that ham radio is a specialized niche market and that amateur HTs don’t benefit from the economies of scale which allow vastly more R&D to be spent on a smartphone costing a similar amount of money. But then I realized that perhaps the critics had a valid case. Manufacturers of smartphones don’t completely reinvent the wheel whenever they release a new model. They just design the hardware. But the hardware is a platform. On it runs a standard OS and various apps, a few of which may be customized to the manufacturer or phone but most of which are generic. Given that software development is one of the most time consuming and expensive parts of any new technology product development, wouldn’t that be a huge saving?

Why can’t top of the range hand-held radios use a similar hardware architecture to cellphones? Instead of a custom design the radio would be a computer running embedded Linux. The RF side could be SDR or it could use conventional technology – it wouldn’t matter, that would simply depend on what is most cost effective and delivers the best battery endurance. But all the control functions, together with transmit and receive audio, would be accessible through an API to software. The user interface would be an app.

Since the radio is a computer the interface would be endlessly customizable and all kinds of things not possible with existing radios could be feasible. Instead of entering local repeater frequencies into memories you could install an app that gets your position from the built-in GPS and shows you the nearest repeaters. One click and you’re listening on it.

Instead of a plain LCD display showing distance and bearing your APRS capable radio could show a full map display just like APRSISCE currently provides on Windows smartphones. You wouldn’t need packet modem hardware in the radio because packet generation and decoding could be done in software. In fact there would be no such thing as an APRS capable radio. The platform would be the same – if you wanted APRS you would just install the APRS application. If you wanted Echolink you could add the Echolink application. If you wanted D-Star you could buy the D-Star app from Icom. If you wanted to work satellites then I’m sure someone would write an app that would keep track of where the satellites are and even control the radio frequencies taking account of doppler.

You could power this hypothetical next generation radio using cellphone battery packs, which are a lot cheaper than the custom battery packs for traditional ham radios. You could even use standard cellphone accessories.

So why won’t this happen? I guess the reason for that is that Yaesu, Icom, Kenwood and the rest don’t make cellphones. Their business is making radios that are intended to be as dumb as most of their users. Ham radio is just an offshoot. The market just isn’t big enough to justify developing what for them would be a completely different and unique hardware platform. So I guess for the foreseeable future we’ll be stuck with our geeky walkie talkies and the cool stuff will all be on cellphones.

ChangeDetection.com once again alerted me to a change in the NCDXF/IARU International Beacon Project status page so that I can manually update the beacon status file for VOAProp. I think it is worth a comment on the fact that 7 out of the 18 beacons appear currently to be off the air. This is the most I can recall being off at the same time. Some have been off for months. If you rely on the beacons to see whether a band is open, you may think conditions are worse than they really are. I hope all the beacons are soon restored to full operation.

Several ham radio blogs have linked to the Wired article Why Ham Radio Endures in a World of Tweets. “What is it about a simple microphone, a transmitter-receiver and the seductive freedom of the open radio spectrum that’s turned a low-tech anachronism into an enduring and deeply engaging global hobby?” the author asks. He goes on to describe the thrill of establishing a direct, person to person long distance contact and exchanging QSL cards, which he contrasts with “a world of taken-for-granted torrents of e-mails, instant messages and Skype video-chats.” It’s a point of view that QRP enthusiasts and many others will identify with.

In the comments to the article many have been keen to say that ham radio is not low tech, citing “VoIP Radio” and digital techniques as examples. They may be true, but I’m afraid the commenters miss the point. The more high-tech ham radio becomes, the less magic there is. Developments like D-Star are about as far from the concept of a simple transceiver and the freedom of the open radio spectrum as it is possible to get. It isn’t simple, it isn’t free (since it depends on a network controlled by someone else) and it isn’t open. Which is why it is anathema to many of us.

There is a danger that the pursuit of technology could turn ham radio into a poor copy of existing communications networks. Ham radio has endured because it has held on to its traditions involving relatively simple technology that most hams can understand and even build for themselves. If we ever lose sight of that the hobby is as good as dead.

Roger G3XBM has started a new project: a simple sideband transceiver for the 10m band. Roger’s projects are always interesting so this page will be one to keep an eye on. If it can be made small enough to fit into a hand held case this could make a great portable radio capable of DX contacts during the sporadic-E conditions during the summer.

Regular readers will know that last year I worked the Czech Republic using a hand-held Intek H-520 FM transceiver with a telescopic whip. The Intek, despite being a nice looking radio, is actually a horrible piece of kit with a PA that sucks the power out of the rig’s batteries, especially if the antenna presents anything other than a perfect SWR. And the trouble with 10m FM in the summer is that too many people are trying to use too few frequencies so there is terrible QRM and the “capture effect” means that only the strongest station is heard.

A little double-sideband rig, even with only a couple of watts output, ought to work much better. I shall be following Roger’s project with interest and intend to make this my next radio project too.

Series Four Episode Four of the ICQ Amateur / Ham Radio Podcast. News Stories include:

• Reduced Height Antennas
• UK Space Agency announcement
• Amateur wanted for UK Space Agency
• Technical clinics at Kempton Rally
• Hams broadcast info out of Egypt
• Why ham radio endures in a world of tweets
• ISS releasing Ham Satellite
• UK Propagation charts for February 2011
• Balloon launch opportunity
• 1st CASHOTA activation of Blackrock Castle
• Voice of Russia on 7200 kHz
• Icom America releases radio transceiver

Steve Nicholls (G0KYA) Propagation Report , and Martin (M1MRB) discusses propagation, antennas and more with Steve Nicholls.

I’ve decided to take on a “new old” project and port my PIC keyer code to the Arduino platform.  I use the word “port” loosely as the Arduino offers many higher level features and libraries, and I will be programming in C rather than the PIC’s native assembly code.  I know I’m about two years late to the start of the “Arduino party”, but from what I’ve read it looks like the party is still going strong with new people joining the fun everyday.

I started writing the PIC keyer about 10 years ago, first starting with PICBasic.  It quickly became apparently that PICBasic, while easy to get started with, produced much too bulky to pack in the features I was looking for.  This is often the case with high level languages.  I went on to assembly and ended up making a full blown keyer with memories, straight key and bug modes, variable weighting, code practice mode, a frequency counter, and several other features.  I look back at the code and can’t believe some of the stuff I did.  I think my two biggest accomplishments were writing and debugging the frequency counter code and making the variable frequency sidetone output while simultaneously doing other functions without the benefit of interrupts and multitasking.  Some of this code is just pure magic and trying to figure it out today I find myself cursing the younger me who was more clever and diligent than the older me today.

The PIC will always be my first love, but I’m ready to move on.  Despite having written very modular and readable code with lots of comments, it’s a major undertaking adding new functionality to this assembly code, especially when I don’t look at the code for months at a time.  Also, I was often having to deal with memory limitations, and when porting the code to bigger chips with more memory I had to deal with memory page issues.  While I could spend the money to get a C compiler for the PIC, it just doesn’t make sense with the popularity of the Arduino platform.  And with all the modules you can get for functionality like memory cards, Ethernet interfacing and wireless networking, there’s just much more potential for growth, doing cool stuff, and reaching a larger user audience.  These days I would rather spend my time making a chip talk over TCP/IP than figuring out how to stuff more assembly code into 500 bytes of remaining memory just to do something like blink an LED.

I expect porting the main CW keyer functionality over to the Arduino will be much easier than the initial PIC development was due to the Arduino’s interrupt capabilities.  Also, the Arduino library has a sound generation library that appears to operate “in the background” while the main code is running.  This is heaven compared with what I had to go through to get sidetone output to work while not missing a beat with CW element timing on the PIC.

I’m awaiting an Arduino board to arrive in the mail; hopefully the fun will begin later this week.  I’ll be posting my progress here.

And on a somewhat related note, it never seems to get reported by “mainstream” amateur radio media, but Sunday, February 13th will be the four year anniversary of the elimination of code test in the US.  Please turn on your rig, start at the lower edge of your favorite HF band, run the VFO up through the band, and listen to all the CW (OK, ignore the RTTY this weekend).  If the spirit moves you, why not have a CW QSO?  Remember – CW is alive and well because of us, not a test.

One problem I have noticed with the PIC TNC I recently built is that it is less tolerant of different packet signals than any of my radios. It decodes my two Kenwood transceivers just fine but it will only decode the VX-8G at a specific audio level that is impossible to set when using the fixed output of many radios. And it won’t decode my WX-1 weather station at all.

My Kenwood TH-D72 won’t decode the weather station either. However it is the VX-8GR I am more concerned about. With the volume of the packet channel turned up, it’s braaps sound a bit thin and weedy compared to those of the Kenwoods and other radios I hear over the air. I thought that I would try to analyze the signals to see if this would give me an idea of what was causing the problem.

I used Spectran, the only free software I know that will do audio spectrum analysis. The receiver was the old Kenwood TH-205E, which being over 25 years old had IF filtering wide enough not to cause any deviation limiting. Each capture was made at the same volume level so the signal levels shown should represent the relative signal deviation.

Because packet bursts are fleeting it took a few attempts to capture the screen at just the right moment. But eventually I obtained plots for each of four radios, including the weather station. Incidentally I am puzzled that the spectrograms show a comb of frequencies. I thought 1200 baud packet was FSK using two frequencies, 1200Hz and 2200Hz. I have seen this before when using sound card decoder software for packet but I have always been puzzled by it.

The top two plots are for the two Kenwood radios. They look pretty near identical. In the absence of any test equipment to actually measure the deviation levels I have to assume that these two radios were correctly set up at the factory and represent the ideal signal to aim for. It is interesting that the highest frequency which I would have assumed to be 2200Hz actually peaks at about 2235Hz. The peak closest to the lower frequency of 1200Hz is actually 1185Hz. But there are six peaks at intervals of about 150Hz between the two and some spaced the same distance going below the lower frequency. I’m sure there’s a reason for it.

If you look at the plot for the VX-8G the top peak is at about 2230Hz and 5dB weaker than the corresponding peak of the Kenwood traces. The other peaks are lower still with the one at about 1180Hz around 8dB lower than that from the Kenwood. Some VX-8 users have complained about low packet deviation of the radio but have been told by Yaesu that it is within specification. As far as I know there is no adjustment to increase it. You would have thought from this that I would need to increase the audio level to get reliable decoding of the VX-8 compared to the Kenwoods. In fact, I have usually had to reduce it a little. As previously stated, the volume setting at which the PIC TNC will decode the VX-8G is quite critical, whereas the Kenwood signals would decode over quite a wide range of audio input levels.

When you look at the signal from my WX-1 weather station, which is modulating a Radiometrix VHF transmitter module, the peak signal levels are close to that of the Kenwoods. The lower frequency components are in fact a couple of dB stronger. However, it’s clear that the frequencies are too high. The top peak, which should be 2200Hz, is about 2290Hz. And the one closest to 1200Hz is about 1230Hz. When setting up my FoxTrak APRS tracker I had to set the frequencies using the PIC calibration routine as low as they would go before my TH-D710 would decide it, so clearly it is the frequency offset that is responsible for the packets not being decoded. The WX-1 firmware unfortunately does not have a calibration procedure. Either the PIC clock crystal needs to be slowed down a bit or I need to make a change in the source code to shift the frequencies and recompile the firmware.

But it’s the VX-8G that most bothers me most. I wish there was a way to boost the level of its packet modulation and make it more like the Kenwoods.