AmateurRadio.com

After my post about using Winlink on HF using a Robust Packet Radio (RPR) TNC Helge DF8LS emailed to say he was trying out another method for email over HF: SCSmail. It sounded interesting so I thought I would have a go too. The software is a free download from the SCS website, but it won’t be any use without an SCS TNC – either the Tracker like I’ve got or one of the even more expensive Pactor jobs.

To install SCSmail all you do is create a folder for it, copy the downloaded EXE file into it and run the EXE. It will create some empty folders as temporary receptacles for your mail.  Next you need to set the program up. This is accomplished by entering the name and login credentials of your POP3 and SMTP servers at your ISP or mail provider. You also provide the details of where to find your TNC (what com port and so on) and can also set up CAT control for setting the transceiver frequency. I used the Kenwood setting which worked fine with the Elecraft K2 to which my TNC is connected.

SCSmail mail client configuration

SCSmail can be configured either as a client or a server. A client is what you will use to send and receive mail and is what I set up. A server is what your client connects to via radio. I used a server set up by (I guess) SCS.

The setup is:

your email client (such as Outlook Express) -> SCSmail client -> SCS TNC -> your radio transceiver —>  the ionosphere —> server transceiver -> SCS TNC -> SCSmail server —> the internet -> your ISP mail server

One advantage of SCSmail is that you can use your own familiar email client (such as Outlook Express) instead of an unfamiliar one like RMS Express. You can also use your own email address instead of having to use a special one @winlink.org. But you pay a price in speed for this.

To reconfigure your mail client to use SCSmail you simply change the addresses of the incoming and outgoing mail servers (usually something like mail.yourisp.com) to localhost. You can then send and receive mail just as you would normally. This is obviously an advantage if you are setting up an HF mail system for people who don’t want to learn a new way of doing things.

Receiving mail using SCSmail

What happens is the client logs in to your ISP mail server via the radio link to the remote SCSmail server. The first time, it downloads and deletes all the mail from the ISP server so it is a good idea to make sure your inbox is empty before you start. SCSmail supports a list of servers that you can connect to, but none is provided with the program. There is only one server you can use with Robust Packet Radio and that is DB0UAL-9 which uses 3.610 and 14.102 MHz. Having entered the server’s call and set your transceiver to one of those frequencies you click on Connect HF-Server. Then you set Outlook Express to send and receive mail and wait until the client disconnects.

I connected instantly to the server on 20m using 10 watts to my attic dipole. But compared to Winlink’s RMS Express SCSmail is slow. This is probably the penalty for using protocols designed for use on the wired internet over a wireless HF link. Winlink and RMS Express are optimised for HF use. RMS Express creates efficient small text mode emails whereas Outlook Express creates messages that can contain lots of fancy formatting and unnecessary header lines which increase the time to send and receive.

It all worked (or mostly did: the test emails I sent myself and Helge still haven’t turned up.) If I owned a boat or a log cabin miles from the nearest telecoms provider I might find SCSmail a useful facility to have. Even though I haven’t, it was still an interesting thing to try out.

Helge DF8LS has just published a web page showing how to send and receive email on HF using Winlink and the SCS Tracker TNC. I just sent an email to myself (isn’t this one of the signs of madness?) and it was received, so the instructions are obviously good!

A Winlink session on HF

Mention of Winlink seems to cause strong emotions in some quarters. Personally I think using ham radio to send and receive email is rather cool, even if it is too slow to use for today’s level of email use. It’s a pity more hams don’t activate their Winlink account, which is callsign @ winlink.org .

If you use APRS then you can also send and receive email by that means using a feature called APRSlink. The trouble is, I use it so infrequently that I forget the commands. It would be wise only to use it if the APRS channel is quiet like it is here.

A couple of days ago Chris, HB9DDF sent me an email asking how to configure APRSIS32 to work with the SCS Tracker / DSP TNC. Digging through my configuration files to get the information he needed I thought: why not put the 30m APRS gateway back online? It had been off since I went into hospital last year and the K2 and magnetic loop were hardly ever used.

SCS Tracker DSP TNC and Elecraft K2 at G4ILO

I don’t know if propagation is lousy or whether things have changed since I was last on HF APRS but there seemed to be a lot less activity on the 30m APRS frequency today. An hour went by without my receiving anything. I did, however, hear quite often the “whooshing” sound of Robust Packet Radio (RPR) stations a few hundred Hz down. So I decided to configure the TNC to work in RPR mode.

Robust Packet is a mode obtainable in 300baud and 600baud versions that has been designed to take advantage of the capabilities of digital signal processing (DSP) in order to obtain reliable communication over a normal less than perfect HF path. To anyone who has experience only of traditional 300baud FSK packet RPR has too be seen to be believed. Packet after packet was decoded and displayed by APRSIS32 while conventional packet transmissions on the adjacent channel just flickered the DCD lamp and were discarded due to errors.

Robust Packet is a proprietary mode developed by SCS and is only supported by SCS TNCs. As far as I know no description exists that would enable someone to develop a PC implementation that uses a sound card. In that respect it is pretty much like Icom and D-Star. I would much rather use an open standard.

G4ILO-10 joins the Robust Packet Network

But RPR works where the old-fangled 300baud FSK invented to work on the analogue modems of 30 years ago doesn’t. I think it is in keeping with the spirit of ham radio to use state of the art technology where it provides clear benefits to communication.

So G4ILO is now part of the Robust Packet Network.

My Gadget Gangster Parallax Propellor board has just modulated its first APRS packets. This is not down to any clever programming by me. I simply used the Spin APRS Object published by Richard, G3CWI based on code by Alex Erlank.

Richard had to make some changes to get Alex’s code to work and I had to change a few things as well. Mostly they involved replacing Richard’s callsign and position with my own! The AFSK output was connected to the mic input of my old TH-205E using a 0.1uF DC blocking capacitor. There is enough idle time at the start of the packet for VOX to be used if the transceiver supports it. Mine doesn’t, so for test purposes I manually keyed the radio’s PTT.

I found that my packets were not decoded by the Kenwood TM-D710 TNC when I used the option to include a path such as WIDE1-1,WIDE2-1. I’m not up to debugging the code. However, Richard had mentioned that calls less than 6 characters long needed to be padded with spaces so thanks to an inspired guess I found that that this applies to paths like WIDE1 as well.

There is a GPS object included with the code. I haven’t tried the Propellor with my GPS module yet, mainly because the GPS doesn’t pick up any satellites from inside the shack so I’d need to rig up a battery supply and take all the kit out to the garden to test it, where it’s damp and cold. (Yes I know, I’m a wimp.)

The AX25 object contains a section intriguingly called “demodulator” which has been removed. So it seems that there may be some Spin code that would enable the Propeller to be used as a TNC to decode and display APRS packets. That isn’t something I had particularly planned to do, but it would be interesting to see if it works better than the WB8WGA PIC based TNC that I built a year ago which is a bit fussy about the level of the input audio.

One of the options with the Propeller is a touch screen colour TFT display panel. With one of those a suitably clever person could make a very nice standalone APRS terminal. I think there’s an Ethernet module as well, so it could even be an IGate…

In the APRS world a new piece of software has been creating some excitement. It is a soundcard modem for packet radio by UZ7HO. It runs under Windows and emulates the AGW Packet Engine so that it can be used by any program that is designed to work with it. The reason for the excitement is that this packet modem can decode several packet signals on slightly different frequencies in parallel, resulting in many more decodes on HF where it is quite common for stations to be 50Hz or more off-frequency.

Unfortunately I haven’t been able to try the new packet engine as the PTT won’t key my Elecraft K2 and I don’t know why. My K2 CAT cable has a transistor switch on the DTR line which goes to a 3.5mm jack plug that plugs in the K2 key socket. This was originally used for computer Morse keying using software like MixW, but it can also be used for PTT with digital mode software as the key and PTT lines are common. Using fldigi and even using a serial port test program I am able to activate the DTR line on COM2 and the K2 will respond by switching to transmit. But if I use this software modem no PTT ever occurs so although the audio is generated the packet signal is never transmitted. If I was using a SignalLink or other device such as my homebrew USBlink with fast audio derived VOX then this wouldn’t matter but as I have a PTT connection on this serial port I’d really prefer to make use of it.

If I change the serial port to COM3 then the program will key my Elecraft K3, which uses a different serial cable but still uses DTR for PTT. I tried the original AGW Packet Engine, both free and paid-for Pro versions but that won’t key the K2 either. So the problem must be something to do with my K2 CAT cable. But my poor old brain has been having rather a tough time recently with all the treatment making me feel like a bit of a zombie and I’m finding it rather difficult to think things through logically and find the solution which is probably staring me in the face!

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.