AmateurRadio.com

I wonder if readers could help me locate a couple of software utilities I need for current projects?

Screamer 1.7 PIC boot loader (or successor.) This was developed by or for Sparkfun, who have version 1.6 on their website. Unfortunately it only allows serial ports COM1 – COM6, which is not convenient for me due to all the COM ports dedicated to radios and TNCs on my shack computer. Forum posts mention a version 1.7 that lets you enter larger COM port numbers but the links to it are now dead. The version 1.6 download includes VB6 source code so I could fix the problem myself except that I only have VB.NET which is totally incompatible with it (don’t you just love Microsoft?) So does anyone know where I can find a copy of Screamer 1.7 or later?

Programming software for Friendcom FC-201SA UHF Transceiver Module. I purchased one of these a few months ago but have only just got round to using it. However it is operating on its default frequency of 430.000MHz. There is a serial interface that can be used to set the frequency in each of the 16 channels and also set the channel. The manual describes the module’s command set but I don’t really want to spend days writing a program for it. The manual also mentions programming software but it was not supplied when I purchased the module from Elcom Research and their website is now defunct. I can’t find the utility on the download page of the Friendcom website and the email I sent to Friendcom did not receive an answer. Does anyone know where I can find a copy of this software?

In case anyone has what I’m looking for and is thinking of emailing software to me, please contact me first. Google doesn’t just block executable attachments, it blocks the entire email so I’d never even know you’d written. The trick is to put it into a zip file and then change the file extension to something other than zip.

Getting a radio to communicate reliably with a computer proves to be a difficult task for some people. The trouble seems to be caused by USB to serial adapters that corrupt the data when used with certain software or at certain speeds. Whenever these problems are discussed in amateur forums inevitably the question of why radio manufacturers don’t build USB interfaces into their radios (as Icom and Kenwood have started to do) is raised. I think this is a very short sighted view that really does nothing to solve the problem.

To begin, let’s deal with the argument that goes “why force users to buy a serial to USB adapter when serial ports have been obsolete for years.” Users have to use something to connect the radio to the computer and the only physical difference between a serial to USB adapter and a serial cable is that one end of the former is a bit fatter to accommodate the USB electronics. There is little difference in cost between the two cables. Furthermore, just because PCs don’t come with serial ports doesn’t mean that they are obsolete. My shack PC has four – soon hopefully to be increased to six if I can get it to accept the two port board I removed when I upgraded to four as an addition – and installing them is easily within the capabilities of any radio amateur. If you use a laptop you don’t have that choice, true enough, but why force a change on everybody because some people choose shack PCs that have limited expandability?

But the main reason why I think building USB into the radio isn’t the solution is that it doesn’t address the problem. It’s USB – either the hardware or its drivers – that is causing the connectivity problems in the first place. If an external adapter cable is used, users can try a different type if the one they have is not working correctly. If the USB hardware is built into the radio then they are stuck with it and reliant on finding a software solution. That might be a matter of getting the manufacturer to fix its drivers, which is not so easy.

Another reason why building USB into the radio is a bad idea is that it limits choices for users. If you want to connect your radio anything other than a PC, something like a MicroHam controller or a remote control over internet device for example, then you’re stuffed if you’ve got a USB port. Some owners of Kenwood’s new TH-D72 APRS handheld have already found that Kenwood’s decision to provide a USB rather than a serial interface to the radio’s internal TNC means they can’t use Bluetooth to link it to APRS software on another mobile device.

Whenever I argue that switching to USB is a bad thing someone always counters the argument by saying USB can provide a wide bandwidth connection that can handle other things such as audio. As somebody who has sometimes had three USB sound devices attached to my PC I can certainly see how a one cable interface between rig and computer might seem attractive, especially to those who believe that sound card modes need something like a RigBlaster. And I would agree that a fast interface would be a nice thing to have if it was one that was a true universal standard like, say, Ethernet.

But if we are talking about USB, most of my arguments still apply. Built-in USB limits choices. An analogue audio input and output lets you interface audio with other things such as digital voice recorders, TNCs and VOIP devices for remote control over the internet. We’re hams, we’re supposed to be able to handle technical stuff, do we really need plug and play interfaces for our radios?

USB is a technology du jour. It keeps changing, whereas RS-232 and analogue audio are permanent standards. USB 1.0 devices seem still to work with USB 2.0 but now USB 3.0 is starting to appear and it remains to be seen how backwards compatible that will be with older USB devices. Who knows what the computers of 10 or 15 years time will be equipped with? It may not be USB anything but something completely different.

Finally there is the fact that USB depends on software to work: drivers that are operating system dependent. Most serial to USB hardware is at least supported by operating systems other than Windows “out of the box.” I don’t have the experience to know whether that is true for USB interfaces that carry audio or other information. Is anyone using their IC-7600 or TS-590 under Mac OS or Linux?

Even if the manufacturer-supplied drivers work for Windows today, will they work on the latest version of Windows in 10 or 15 years time? If not, will the manufacturer of the radio provide new drivers once the radio is an obsolete model? I’ll bet a perfect but unusable as no longer supported scanner that they won’t. I’m equally sure that I’ll still be able to interface my K3’s RS-232 serial port and analogue line input/output to whatever computing hardware and operating system I’m using then.

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.

I thought packet radio was all but dead. Yesterday I heard Richard MM1BHO mention that there was a packet node in Scotland on 70cm at the same location as the GB3LA repeater which is a monstrous signal here. I asked Richard to tell me the frequency so I could have a listen. I wasn’t optimistic about hearing anything as 70cm has always seemed a bit of a dead loss for me. I had to wait a while to hear anything, and when I did, I found the packet signal was 20dB over S9 which is the strongest signal I’ve ever heard on 70!

I then spent a couple of hours trying to sort out a way of receiving the packet. TrueTTY seemed like a good choice. It decoded the packets and displayed them on its screen. But I couldn’t find any software that would work with its virtual TNC.

I also tried AGW Packet Engine in sound card mode. That, too, decoded packets, so I got the AGW Terminal software as well. But I could not transmit. The software keyed the PTT when it was supposed to, but there was no audio modulation.

Finally I bit the bullet, shut down the APRS gateway and put the Kenwood D710 into packet mode. I then set up AGWPE to talk with the Kenwood’s TNC. That worked, and I was able to connect to the node whose call is GB7WD. I was wondering what to do next when Clive GM4FZH connected to me and I had my first chat over packet radio since the mid-1980s!

I’m afraid after all that time I have forgotten just about anything I knew about packet radio so I’m still pretty clueless as to what to do. I don’t know how to set up a mailbox, or even where to set one up. There seems to be a shortage of material on the interweb aimed at packet newbies (or oldies like me where the onset of Alzheimer’s has erased any memory of what we once knew!)

I think packet radio is something I will enjoy playing with again. I went back to AGWPE soundcard mode and found that the reason I was not getting any audio was because although the software says it uses the left channel which online references claim is the tip of the stereo jack, it was actually present on the ring. After resoldering the connector on the audio cable I was able to transmit packets as well as receive them, and G4ILO is now listening on the GB7WD frequency on the A side of my TM-D710 while my 2m APRS gateway is using the B side. There are just so many things to do in this hobby!

The first bit of live data I received from my APRS VHF propagation alert reflector was a warning of a possible Sporadic-E opening on six metres. I was rather surprised that there was Sporadic-E this early in the year, but I went to the DX Sherlock website and sure enough contacts had been reported between a station even further north than here and one in the Czech Republic. I then clicked on the map to see the actual contact details and was surprised to find they were WSPR spots!

I went to the WSPR website and sure enough the same signals were shown. I decided to fire up WSPR on 6m myself but by then the OK station had gone and no new spots appeared from anywhere.

I have been, and still am, somewhat sceptical of the value of WSPR in showing VHF Sporadic-E propagation. One of the characteristics of Sporadic-E, particularly at the start and end of the season or on the higher frequencies like 2m is that it is very fleeting. A signal can be there for one minute, literally, and gone the next. On the other hand, signals can be really strong when reflected by Sporadic-E. WSPR is designed for detecting weak signals under steady propagation conditions and uses a 2 minute transmit cycle during which the data is transmitted very slowly. It seems to me that what you want to detect Sporadic-E is a mode with short transmit cycles where the data is transmitted quickly, perhaps something more akin to the modes used for meteor-scatter. I wonder if K1JT could come up with something?

Nevertheless I am very interested in anything that helps to detect VHF openings that might otherwise go undetected. I plan on WSPRing more on the 6m band, as long as there are others doing likewise so there is a chance of being received!

I have just set up an ANSRVR notification group (the APRS equivalent of an email reflector) called CDGVHF. The purpose of the group is to alert interested subscribers in the Cumbria, Dumfries and Galloway area to possible openings on the 6m, 4m, 2m and 70cm bands.

The APRS alerts make use of the email alert service of DX Sherlock which sends alerts of possible band openings customized to the subscriber’s location, based on DX Cluster spots and other reverse beacon information. I have set up a subscription to send alerts of possible band openings workable from the IO84 grid locator to a special email address on the G4ILO’s Shack web server. Using a feature of the cPanel web hosting, the email is “piped” to a script written by me in the PHP language. This extracts the subject header of the email which contains a succinct description of the alert, shortens it as much as possible and then sends it as a message to the CDGVHF ANSRVR group, which then forwards it to all interested subscribers.

Why is this better than just subscribing directly to receive the alert emails? Because I can now receive the alerts on my APRS-equipped hand-held, which should greatly reduce the chance of missing a good band opening because I wasn’t in the shack at the right moment.