AmateurRadio.com

Yesterday was one of those clear, blue, sunny, still, cold days that make you think it would be a criminal waste to stay inside. I decided to try another Wainwrights On The Air activation using my WOTA Pole, which had been rebuilt since Sunday’s disaster. My intention this time was to visit the summit of Knott, LDW-082, followed by nearby Great Calva, LDW-095. I took the VX-8GR for APRS but this time I also took the Motorola GP-300 to use for the activation which I hoped would avoid the receiver overload problems experienced with the Yaesu.

The weather may have been bright, but I was not. Sometimes I seem to get periods of a few days when although physically I may be awake, mentally I am not. Fortunately I hadn’t driven far before I realized I had not put walking boots in the car, so a complete disaster was averted. That wasn’t the only silly mistake I was to make, though.

I parked at the head of Mosedale and started walking up the Cumbria Way path. I approached the structure you can see from the starting point, which turned out to be a large garden shed! The path seemed to be taking me near to High Pike so I thought I would make that my destination and visit Knott on the way back.

As I approached the “shed” I heard people making contacts with another hilltopper, Gordon G0EWN/P on Grey Knotts. I took the VX-8GR from the rucksack and made several calls using the helical whip as he completed each contact but he always replied to someone else. After ten minutes of standing around I decided to shoulder the rucksack again and continue climbing while holding the radio. I called several times when Gordon listened for “any more calls” but he was not hearing me. I don’t know why that was – another case of a radio front end being overloaded by high signal levels on the fell-top perhaps?

I reached a grassy summit topped by a tiny cairn and checked my position and realized that I was further from High Pike than I thought. I also then realized that I didn’t have my walking stick! I must have left it by the “shed” when I stopped to try to work Gordon! I turned round and went back. I retrieved my stick, but having wasted half an hour I decided to abandon High Pike and carry on to Knott instead.

I arrived at Knott still in sunshine with clear blue sky, the distant summits slowly disappearing in the haze. Although it was calm enough to try using the WOTA Pole supported in my rucksack I decided to use the guying kit from the MFD that I’d brought with me in case of windy conditions to avoid the trouble I’d had on Sunday. That cost the antenna some height, but on the plus side it allowed me to operate sitting down which I was glad of as I’d been climbing for over 2 hours by this point. Whilst I ate my lunch I connected the VX-8GR to the WOTA Pole and it was picking up APRS packet bursts from as far afield as Norway and Holland. VHF conditions were obviously up.

When I finished my lunch I connected the GP-300 to the antenna. This was when I discovered I’d brought the wrong speaker-mic. One of the hazards of owning too many hand-held rados I suppose! It was not a major problem of course, as I could use the radio without it. I made several contacts from the summit of Knott the most distant of which was G6ODU in Ormskirk, Lancashire, not a bad haul from the North Lakes.

The wind was so calm my Olympus voice recorder logging device was able to make a high fidelity recording of the activation. In case anyone is interested to hear what it sounds like at the sharp end of a WOTA activation here is a recording of about 8 minutes of activity. The loud, punchy audio from the Motorola GP-300 really helps so you can hear both sides of the contact equally well. Some of the quality has been lost compressing it down to an MP3 file of reasonable length but it’s still almost like being there!

I would have liked to stay on the hill longer to see what else I could work, or even move on to Great Calva to activate that, but a thick bank of mist was approaching and I didn’t want to be up there in mist. There are few clear paths on these infrequently walked grassy summits and without any landmarks to aim for it would be easy to get lost. Even though the visibility was clear I still went the wrong way off the fell and hit the Mosedale to Skiddaw House path much closer to Skiddaw House than to Mosedale. That cost me an extra 3km or so of walking to reach the car, by which time the mist had arrived and the sky was a grey murk.

This was long walk for only one summit activated. I could have made more if I’d had my wits about me and things had gone according to plan. But on a day like this it’s good to be out however many summits you activate!

I like to think APRS is a haven from the aggravation often found on the rest of the bands, but unfortunately we have our problems too. This afternoon an APRS message appeared on my screen from G1ZRN-10 that clearly had been addressed to ALL.

It obviously wasn’t intended for me personally. I don’t gate from one band to another. In fact at the weekend I leave my HF IGate receive-only because I don’t want to add to the mayhem. But there is a lot of traffic gated from VHF to HF by stations in the south of France. It serves no useful purpose for me in the UK to receive information about French repeaters or French radio club meetings nor is there any point in gating position beacons from French VHF stations on to 30m. But what can you do?

I don’t think getting your blood pressure up and acting like a band policeman will solve the problem. Unfortunately the language barrier doesn’t help here. Because of that there are no common forums where European APRS users meet, where an approach could be worked out. A direct approach to the offenders would need to be made by a native speaker who could gauge the individual’s attitude, find out why they are doing this, and tactfully dissuade them from it. Blunt emails in capitals and in English could easily have the opposite of the desired effect.

I think it is one of those things we just have to live with. Actually I’m not sure the effect is really that bad. I’m running just 10W to a magnetic loop in the attic and my beacons are reliably gated throughout most of the day by stations in Germany. When European HF mobiles are about I often gate them, so the network still works. But it would be nice to have a blacklist function in my IGate software so that I can refuse to pass traffic for the offending stations. If everyone did that, it might get them to mend their ways or get off the air.

Some folks have set up an alternative APRS network on 20 metres called Net14. I don’t think that’s the answer. Sure, you get away from the idiotic VHF to HF gateways, but you get away from all the other activity too. I tried it a couple of times and it was even more boring than VHF is here most of the time.

If anyone has any serious suggestions as to how to solve the problem of cross-band gating on 30m I’d be glad to hear them. Or even non-serious ones. Right, I’m off to bid for a GPS-guided missile on eBay!

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!

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.

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.

I have been playing around some more with the WB8WGA PIC TNC that I built. While it was quite fun to see what it managed to decode and have it working as a digipeater, I eventually wanted to get it talking to some real software. UI-View is supposed to be able to work with TNCs in Converse mode, so that was going to be the easiest thing to try. But in order to do that I needed to solve the problem of the firmware expecting a linefeed to terminate a command.

That problem turned out to be fairly easy to solve, though I ran into some problems by trying to make some other changes. The trouble with working with microcontrollers, at least when using assembler, is not just that they don’t have much memory but it isn’t an a seamless block and you have to take care of memory management. Consequently I found that adding one line of code could make the difference between the program compiling and getting an error on the lines of “you are writing to a location that has already been written to.” I’m a high level language kind of guy who expects the compiler to take care of all this for me. I suspect that major modifications to the code like adding KISS support is going to be beyond me.

Anyway, I managed to get it so that UI-View could make its various settings and put the TNC into Converse mode. I had to get rid of the message that comes up on entering Converse mode because it often clashed with UI-View sending a beacon. I then set some IS to RF gating options to generate a lot of traffic and found that the TNC kept going back into command mode. This appeared to be due to the timeout timer that throws you back into command mode if you start to type something and don’t hit Enter. This was a pretty annoying feature, quite apart from interfering with reliable operation, so I had to take that out, too.

It seemed like the TNC was ready to go. But although it would transmit beacons from UI-View perfectly well, the program would not display any received stations. I could see the decoded packets in UI-View’s Terminal window, but they never appeared on the map anywhere. I did some searching and found one complaint about this in the Fox Delta Yahoo! group (the Fox Delta Mini TNC is apparently based on the same firmware) but no solution.

There did not seem to be anything wrong with the packets and I spent a couple of hours trying various things to see if I could establish what the problem was. Eventually I hooked UI-View up to my Kenwood TM-D710 in packet mode and watched what happened. Packets were received and displayed as expected. So then I connected a terminal program to try to see what the received packets looked like. (This is Windows HyperTerminal with a special Terminal-Hex font that shows the hex value of non-printable characters.)

This is what the output from the Kenwood TNC looked like:

and this is the output from the PIC TNC:

As you can see, the only difference (apart from the fact that the PIC TNC is displaying the packets as it digipeated them while the Kenwood heard both the original and the digipeated versions) is the text UI or UI R in angle brackets before the colon that marks the start of the payload part of the packet. It doesn’t look like something significant enough to make UI-View ignore the packet. It isn’t something that appears in the raw packets listings at aprs.fi. I don’t know what it means or how to generate it in the output from my TNC. So I’m stumped at the moment and am hoping that someone who knows the answer will read this and point me in the direction of a solution.

I have mentioned before that when I’m not in the shack I like to run a little program called aprsg to gate all the local APRS activity to a UHF frequency so I can see what is going on in the local APRS world using an APRS-capable HT. I have set up a system using sound card software, a USB sound device and my FT-817ND to do this. But I would like to make a standalone box for this. The first step in this project is to find a simple, cheap TNC.

There are products that would fit the bill from Byonics and Argent Data. Unfortunately they are not available in the UK and the cost of importing these kits from the US makes them less than cheap. I looked at the Fox Delta Mini TNC. But that is not a KISS TNC, as was confirmed by an email to Dinesh, the proprietor of Fox Delta.

Whilst searching around for possible solutions I came across a design for a TNC using a PIC16F88 microcontroller by WB8WGA that was originally published several years ago as an article in the ARRL experimenter magazine QEX. It has been modified by DJ7OO and ZL3AME, who had developed a stripboard layout for it. I had all the bits apart from the microcontroller and the clock crystal, which were quickly sourced on eBay. So I thought it would be an interesting project to build and experiment with.

ZL3AME’s stripboard layout results in some quite lengthy signal paths. Despite this, the TNC worked first time, with just a minor glitch caused by my mis-wiring the PTT connection on the transceiver connector. (I have a standardized interface that I use on all my projects, with an 8-pin mini-DIN connector for audio and PTT to the transceiver, and a 6-pin mini-DIN connector for serial and GPS connections. I can then have a standard set of cables to hook the projects up to any radio, connect to the computer or a GPS, etc.)

With all the bits of APRS kit I have it was easy to generate some test signals and I soon had packets being decoded on the terminal screen. I wondered how sensitive the TNC would be as it uses the PIC16F88 to do the decoding instead of a modem chip like the MX614. I have not seen any DX packets decoded yet, but it does seem that decoding success is dependent on the audio level into the TNC. All of my APRS generators were decoded with the exception of my weather station, which has rather low deviation. When using the old Kenwood TH-205E as a receiver I could increase the volume so the weather station was decoded, at the expense of reliable decoding of the other radios. That was not even an option when using the DATA output of a radio, which has a fixed level. I suspect that performance could be improved if you could add an audio ALC on the input.

The TNC can also send APRS beacons and work as a fill-in digipeater. To send a fixed position you can simply encode the position co-ordinates into the beacon text. There are also a couple of jumpers that allow you to connect a GPS to the serial port, which would allow the TNC to work as a standalone tracker. I haven’t tried that, since I already have a standalone tracker. There are no Connect or Disconnect commands so it cannot be used as it stands for packet radio.

This is not a KISS TNC, so it can’t be used with APRSIS32 or aprsg or any of the software I use. I installed UI-View which apparently has the ability to use a TNC for APRS in Converse mode, but it doesn’t work with that either. I think that is due to the fact that the TNC expects CR/LF at the end of each command instead of just CR, so fixing that will be the task of my first attempt at modifying the firmware. Other things I would like to try are making it work at 300baud (for HF packet) instead of 1200baud, and implementing KISS mode. In KISS mode the PC software provides the complete packet and the TNC just has to add a CRC and send it. So in theory it should be simpler to implement than the existing code which has to construct an AX.25 packet from the information entered plus parameters previously set in the configuration. We shall see. The TNC source code is written in assembler, and trying to understand assembler code is to me like not being able to see the wood for the trees. But it will be a good incentive for me to look “under the hood” at how APRS, packet and AX.25 really work.

Many of the links to original information about this project seem now to be dead and I had to do quite a lot of searching to collect the information I have. For the benefit of anyone else who would like to try building one of these TNCs I have assembled all the files and information I found into a zip file which you can download here.