AmateurRadio.com

The best APRS client just keeps getting better. The latest treat for beta testers of APRSISCE/32, the APRS client for Windows desktops and Windows Mobile (which also runs under wine on Linux) is configurable map tile servers. This feature allows users to switch between a variety of different map servers to use a range of different maps in addition to the default OSM mapping.

Probably the most useful for most users will be the Mapquest OSM mapping which is a high contrast map similar in appearance to a road atlas. Mapquest also has a set of satellite view tiles, shown above in a screenshot from my 30m APRS gateway. These tiles don’t unfortunately let you get closer than about 10,000 metres so you can’t zoom in on somebody’s house like you can with Google mapping.

For UK users especially those of us in hilly areas the ability to use the UK specific Freemap mapping is a massive benefit. These OSM based maps show topographical detail (contours) as well as footpaths and walkers’ routes as illustrated by the screenshot below centered on a recent SOTA activation in the Lake District.

The ability to seamlessly pan and zoom around an area as well as switch map types with a couple of mouse clicks puts APRSISCE/32 miles ahead of UI-View. This new feature is another example of the amazing dedication and support given by Lynn, KJ4ERJ, to his program. Only last weekend while Lynn was on a trip to Spain a handful of us were discovering and sharing details of alternative map sources and hand-editing them into the configuration files so use the maps with the software. On his return the suggestion was made that it would be nice to be able to switch between map sources from within the program. Four days later, we’re testing the new feature. It’s like Christmas every day when you’re an APRSISCE/32 user!

My homebrew WX-1 weather station, which transmits data directly on 144.800MHz APRS using a PIC based packet modulator and a 10mW VHF transmitter module, is decoded by my VX-8GR and my Kenwood TM-D710 but not my TH-D72 or my homebrew TNC. This is annoying. A week ago I looked at the packet modulation from various devices and found that the tone frequencies of the WX-1 were about 50Hz too high. So I thought I would try to fix it.

The PIC source code for the weather station is available for download. The program code that generates the packet modulation is a bit beyond me, but I think it works by executing a loop and pushing binary values out of 4 ports which are connected to 1K0, 2K0, 3K9 and 5K1 value resistors in such a way as to produce a stepwise approximation of a sine wave. It seemed to me that to lower the tone frequencies I needed to slow the loop down a tad. After a bit of trial and error inserting a nop (no-operation) instruction in various likely-looking places I managed to get the tones nicely symmetrically positioned around the 1200Hz/2200Hz nominal frequencies for 1200baud packet. But the TH-D72 and homebrew TNC still refused to decode any packets!

Wondering what to try next, it occurred to me that the tone frequencies were not the only parameters of a packet signal. There is also the baud rate. I also remembered that the MixW sound card software prints out the measured baud rate next to each decoded packet. So I hooked MixW up to a transceiver and sound card and gave it a selection of signals to decode. I found that whilst my two Kenwood transceivers and the Yaesu VX-8GR all measured 1200 or 1199baud, the WX-1 recorded a value of 1208 baud. That had to be the cause of the problem.

Unfortunately I can’t find a solution. I thought that slowing down the PIC processor’s clock might make the necessary adjustment, so borrowing an idea from a PIC frequency counter circuit I replaced one of the fixed capacitors on the oscillator crystal with a variable one. This made a whole 1 baud of difference! Clearly that approach isn’t going to get me anywhere unless I get myself a 19.867MHz crystal. If I’d done the math in the first place I’d have realized I wasn’t going to pull the oscillator that far with a trimmer.

The solution, if there is one, has to be in the code. But I don’t understand it nor can I find any comments that would point to a routine or value that affects the baud rate. Give me a circuit with discrete components any day. If this is the future of electronic experimentation I don’t think there’s a place for me in it.

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.

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.