
Being in a remote location with limited infrastructure and occasional disasters of various flavors, I thought it would be a good idea to have some options to get email on and off the island without relying on local communication providers. There are some satellite phones around, but a limited number, and bandwidth is still costly. I have found two ways to get email off the island using amateur radio: APRS via satellite and via HF. I managed both with equipment already on hand and no additional expense.
Both systems rely on some sort of gateway receiving station to route the email to the internet. I’ll focus on HF because it is more robust and more likely to be available at any given time of day.
Email via APRS
First, though, a word on APRS. APRS is meant to send short messages via packet radio. The only VHF APRS digipeaters near me are in low earth orbit on amateur satellites and the ISS. I have been successful in sending APRS messages via the ISS and having them received within the footprint of the space station, in South Africa and Reunion. The APRS protocol allows for very short email messages to be passed in a single APRS transmission, and this would suffice to pass a contact phone number, an “I’m okay” message, etc. In principle, there may be a way to string together a few APRS bursts to send a longer email, but I have not gotten that to work. You can’t guarantee that every APRS burst sent will be received intact and repeated.


To send the short message, I programmed the formatted message into my VX8GR HT (which has a built-in but limited AX.25 TNC), connected the HT to an Arrow 2 antenna, plotted the pass of the ISS on a cell phone app, and hit the transmit button. When the ISS was in position, I heard the re-transmission and registered the packet on my HT. That only gets the messages re-transmitted — it still needs to be heard by a ground-based internet relay station, though, to be forwarded as email. There are a limited number of these stations, so in less populated areas of the world, this is far from a sure thing. This method also requires line of sight to the satellite, so I would not like to try this in the middle of a cyclone, since it would be no fun standing outside with an HT, phone, and tripod-mounted antenna in hurricane force winds and maybe lightning. I suppose if I had a permanent satellite station in the house, that would not be as much an issue. It does speak to the need to get more ground-based relay stations deployed to make this a more viable option globally.
Email via HF: Pactor
HF-based email is a better solution, despite the inherent limitations in data rate available using relatively narrow bandwidth transmissions on bands prone to all sorts of noise.

A few years ago, I mentioned fixing up an 80s vintage Pakratt 232 model PK-232MBX terminal node controller (TNC) on the blog. This device connects via a serial port to a computer and interfaces to a radio, allowing you to send and receive messages in various modes including HF and VHF packet, RTTY, AMTOR, and PACTOR. That last mode is of particular interest, because it is the main mode used by Winlink (formerly, RMS-Express), to pass email over HF links to base stations throughout the world. This system is used by a lot of mariners and between the long range of HF radio and the number of base stations in service, there is essentially global coverage.
Pactor is a proprietary standard, and as far as I know cannot be emulated as a soundcard mode (presumably, unless a license is obtained). It is usually implemented as an external modem that connects between a computer and radio. Over the years, there have been improvements in Pactor to increase speed and ability to operate despite noise. The first iteration of Pactor, the one implemented in the PK232, was Pactor 1, with a data rate of 200 bps, which could fall back to 100 bps under poor conditions — painfully slow compared to even dial-up modems, but good enough to pass email-sized texts. Subsequent versions 2, 3, and now 4, each upped the speed, which is a big deal if you want to send reasonably sized attachments with the emails.
The drawback to Pactor is that with every iteration of the standard, the modems have become more and more expensive, with current ones priced near $2000 USD. If you need the speed and reliability, the cost can be justified, but if you use the system infrequently and just want to be able to pass short messages, getting ahold of an old PK232 on ebay will likely run less than $50 USD. There were a lot of PK232s manufactured over the last few decades, and I believe even the oldest ones included Pactor-1, so you can sometimes find a pile of them going for a song at hamfests.

Before I started setting up the PK232 for pactor, I made sure that there are some gateway stations within reliable distance for my station, based in Antananarivo, Madagascar. Bringing up the map of pactor gateways, I see that the closest is in Maputo, Mozambique, and another nearby in Pretoria, South Africa. Stations in Cape Town, South Africa and Namibia are also likely to be routinely within range under favorable conditions.
I am using my Kenwood TS-450 for this project, and when operating in a high duty digital model like pactor, I will drive it at 50W output. My antenna farm consists of a hexbeam (6m-20m), a 30m vertical, and a 40m delta loop. These antennas match up well with the frequencies used by the four regional gateway stations, and based on my experience with propagation, I would expect to be able to hit at least one of these stations with a reasonable signal most hours of the day under usual propagation conditions.
Set Up of PK232
To begin, I connected my computer to the TS-450 using a CAT interface. This consists of a USB-to-serial adapter, and some level conversion circuitry. The serial connection is set to the radio’s default parameters of 4800 baud, 8 data sites, no parity, and 2 stop bits. This connection allow the radio to send commands to the radio, like setting the frequency, mode, etc. You could get by without this connection if necessary, making these adjustments by hand. From pactor’s point of view, the radio is just a link.
Next, I connected the computer to the PK232 using a USB-to-Serial converter and plugging into the PK232’s 25-pin RS-232 connector. After plugging the USB/Serial converter into the computer, I took note of the new serial port that appeared in Windows Device Manager (in my case, COM14). Next, I opened a terminal session to the PK232 over the serial connection. Last time I did this, my computer was running WindowsXP and I used the bundled Microsoft Hyperterminal program. I didn’t see this on my newer Windows 7 computer, so I downloaded a free copy of Putty, a swiss army knife terminal emulation program.

Under the configuration options in Putty, I edited the serial connection setup to COM14, 9600 baud, 8 data, no parity, one stop bit, and xon/xoff flow control. I think I left everything else default. When you hit “open” under terminal, a new window should open. If there is no response to hitting return a couple times, send a bunch of asterisks (i.e., shift-8 on US keyboards) until you get a prompt, “cmd:”. The asterisk allows the PK232 to detect and automatch the communications parameters of your terminal. Once you see “cmd:”, you should be able to type commands to the PK232.
The PK232 has an internal battery and should have its previous settings in store. One problem that I ran into was that if I hit the carriage return, I would not see a line feed on the screen — it would display “cmd:cmd:cmd:”. To fix that, I had to type “echo on”, a command to the PK232. At that point, the display scrolled properly.
The PK232MBX manual is available for free online and goes into detail about all the technical specifications of the PK232, how to operate each mode, and includes an appendix which lists all available commands. The PK232 can also provide live help, if you type in the “help” command. One useful command is to dump all current parameters to see how the current state of the PK232, “display z”. You might want to turn on logging in the terminal program and capture the output of that command for reference.
Next, you need to make connections between the PK232 and the radio. In one direction, the PK232 has to be able to hear the signal coming in on the radio to decode it. In my case, I took the audio output from the ACC2 jack on the radio and ran it to the 5-pin connector on the back of the PK232 (pin out of the jack is available within the Kenwood TS450 manual, also available online at no cost). I could also have brought it into the PK232 through the 3.5mm jack. I chose the ACC2 connector rather than one of the headphone connectors because the ACC2 volume level does not change when you adjust the AF gain dial on the front of the radio. You can still listen to the radio and make it as loud as you find comfortable, without altering the level going to the PK232.
For the connection in the other direction, from PK232 to the radio, one option would have been to used audio output from the PK232 and to have brought it into the radio’s microphone port, for example, via an interface like a rigblaster, which would put an audio isolation transformer in the pathway to provide some galvanic isolation. The same could be done with the ACC2 port’s audio input pin. Pactor, like RTTY, is a form of frequency shift keying. In Pactor, the two frequencies, termed mark and space, that are 200 hz apart. The PK232 “listens” around a center frequency of 2125 Hz. So, to operate using audio frequency shift keying (i.e., sending sounds to the radio), the radio would be set to upper side band (USB) mode and the dial (suppressed carrier frequency) adjusted to about 2125 Hz below the center frequency of the gateway station. That puts one tone about 100Hz above the center frequency, and the other 100Hz below it.
In my case, I chose to key the rig using a hardware on/off connection rather than sending audio. I did this for three reasons:
- This particular radio has been reported to be susceptible to RF interference with AF signals at the ACC2 port. I have also experienced using a rigblaster and the mike port before I put an RF choke on an end-fed antenna. Instead of sending audio from the PK232 to the radio, I chose to use on/off keying, which should be immune to RF. I took the FSK output from the PK232 and brought it over to the FSK pin (3) on the ACC2 port.
- In AFSK mode, I can select a USB filters, which are about 2300 Hz wide. This chops off the higher frequency noise, but I’m really only using the top 200Hz of that bandwidth. In FSK mode, I can apply the tighter CW filter (450 Hz) around the center frequency and exclude neighboring noise, improving the S/N ratio.
- I also intend to set up the same radio for sound-card modes using the microphone port and would prefer to have no other audio going into the rig.
On Air Testing in RTTY mode
To make sure all of this worked, I set up my radio for RTTY (170 Hz mark/space split on menu item 37) and followed the directions in the PK232 manual to run RTTY using the command line. This is quite a different experience from looking at a waterfall on a sound card mode. I heard a signal, tuned it in using the PK232’s bar graph, and adjusted the detection level (DCD) knob on the PK232 to exclude noise. I also routed the mark/space tone output from the PK232 to my crossed bananas display, which I find more intuitive for tuning in signals, but it’s entirely optional.
When transmitting, I set my power to full and adjusted the carrier to the point that I had 50W output and no compression on the ALC meter. After a while, I got the hang of typing “X” to transmit, typing my outgoing message, and hitting CTRL-D to get back to the command line. Very old school, but it worked. I called CQ for a while, and worked a bunch of stations. It took a little getting used to tuning them in using the RIT control (to change the receive frequency without altering the transmit frequency) to center their signals, but I was able to have clear exchanges with a small pile up of stations eager to get a RTTY contact with Madagascar into their logs.
On Air Testing in Pactor Mode
Pactor is very similar to RTTY, but I had to switch the radio’s mark/space interval to 200Hz. Unlike RTTY, pactor is does not care which frequency is above/below the center frequency, so FSK and R-FSK mode setting makes no difference. While, pactor can be sent directly from the command line. I don’t think people typically make HF contacts station-to-station in pactor any more given faster modes like PSK31 and RTTY, but the manual details how you could do so. To send pactor, you need to set your pactor call sign, type “myptcall XXXXX” at the command prompt, where XXXX is your callsign. Next, put the modem into pactor mode by typing “PT”. At this point, it worked just like RTTY: typing “X” at the command line will key the rig, and if you can hear the send tones using another radio to confirm that everything is working as expected.
Setting Up Winlink
To send an email to one of the Winlink stations, you need to first download (free) and set up the winlink software. As the name suggests, it runs under Windows. In my case, I had no problem running the latest version (at time of writing) under Windows 7. You will also need to register your call sign, which does cost $24. Once registered, a call sign remains on the books indefinitely unless you go 400 days without making use of it on the air, through Winlink. This fee helps support the infrastructure, which is also used as emergency communications backbone. The slight barrier to entry also probably prevent random unlicensed users from gumming up the works.

Registering a callsign
I found the program’s help system adequate to get everything set up and running, with one technical hitch. After downloading, just click the program icon and it should uncompress and install. Fill in the information screen and follow instructions to register a call sign. Once registered, you will get an email with your registration key, which should also be entered on the information setup screen.
Sending a test message via internet
Next, to make sure that the non-radio part of Winlink was working, I opened a telnet session. Winlink can operate on top of various communication layers, and if you have connectivity, it can just route its message via the internet. I created a message to one of my email accounts (“new message”), saved it to the outbox, opened a telnet window, and watched it send. A moment later, it showed up in my regular email.
Sending A message via pactor
Next, I opened a pactor session and set up the radio and TNC. Under radio, I selected “Kenwood” from the drop down box and made sure the communications parameters were right. Under TNC, I selected PK232. That’s about it.


The program can update itself from the internet regarding available gateway stations, so I let it do so. It can also tell you which station is in optimal range given propagation if you install the optional propagation prediction program, ITS HF, which is worth doing. Again, I just followed Winlink’s help system instructions to do this.
Now, after opening a pactor session, you can display a list of available stations ranked by predicted link reliability. This is just a guess, so you might actually find that some links work better than others under real life conditions.
At this point, you should be able to hit “start”, and Winlink should start sending handshaking signals to synch with the remote gateway, but this is where I hit a snag. When I did this, the PK232 lights flashed and set mode to Baudot, indicating a reset. Winlink displayed error messages about not being able to connect to the PK232 or to connect in HOST mode.
When I connected with PUTTY, I saw that the PK232 had been reset to default values – it had no memory of previous settings like MYPTCALL. This was a head scratcher, because I knew the serial connection was working (I was using it), and that the whole set up worked in pactor mode using the terminal program. All I was left with was that it was some interaction specific to the Winlink program.
I traced the problem down to my USB/Serial adapter, which used a Prolific driver. I recalled some issues with counterfeit chips sets and bad interactions with .NET program. It may also have been some unpleasant interaction between the particular driver employed and Windows 7. In any case, swapping out that USB/Serial interface with a known good FTDI-based converter did the trick. Now, when I hit “start”, the PK232 would key the radio and the radio would send FSK tones.
When you select a gateway station in the pactor session window, Winlink sets the radio to USB mode and sets the dial frequency appropriately for AFSK. Since I’m using FSK, however, I need to switch mode to FSK on the radio and return to 100Hz (ideally, 85 Hz) above center frequency (which you can read in Winlink’s pactor session window). Maybe there is a checkbox somewhere to tell Winlink that I am sending via FSK rather than AFSK, but if so, I haven’t found it. It’s not a big inconvenience, but any suggestion to correct this would be welcome.
After configuring the radio as above, I listened for a bit and heard the gateway station a couple times. Its tones were centered according to the bar graph on the PK232 and I adjusted the DCD knob to squelch out background between packet bursts.
When I hit “start”, the radio began sending short synching bursts. I again adjusted the carrier so power out was 50 watts and I had no deflection on the ALC meter (compression could distort the signal). After a couple bursts, I heard similar answering bursts from the remote station, and then more chatter as the connection set up. After a moment, text printed in the session window indicating that the remote connection was established. I had queued up an email in my outbox, and it was dutifully sent through the connection, moving to my “sent” box. A moment later, I confirmed on my cell phone that the test message sent over the air had been received by my gmail account.

Email via Winmor
Pactor is great, has a long track record, and there are plenty of pactor gateways, but its proprietary nature makes it expensive, particularly if you want to send messages at more than a snail’s pace. It was almost inevitable that an open standard sound card-based mode would develop to compete with it: Winmor.
Pactor developed in the days when all the signal processing magic occurred in modem hardware, which was controlled by a dumb terminal. But since today’s PCs have CPU cycles to spare, Winmor economizes by doing all the signal generation, detection, processing, and error-correction in software. Sound goes in and out through a PC’s sound card, the only hardware needed are the lines that bring audio to/from the radio and a way to key the radio to transmit.
There are a lot of sound card interfaces, rig blaster and signalink are two common brands. I have a rigblaster NOMIC, which takes sound output from the computer, runs it through an audio isolation transformer, and brings it to the mike connector on the front of the radio. The audio from the radio can be brought directly to the computer. In my case, since I had already brought audio from the radio’s ACC2 port to the PK232, I ran a 3.5mm shielded cable between the PK232’s “audio in” port and the computer microphone card, effectively looping the audio through the PK232. The extra path did not reduce audio quality or make it susceptible to picking up RF.
In fact, once I had this setup working, I inserted a DSP audio filter in the line as well. When this radio was manufactured, DSP was available as an add-on external unit, the DSP-100. This filter will not help with strong adjacent RF signals that desense the receiver, but it will allow you to narrow the audio pass band to exclude adjacent signals and noise in the audio. Again, this bit of gear is optional.

When Winlink connects to the internet during setup, it pulls down a worldwide list of stations and their capabilities. The same list could also be pulled down over a radio link. Again, I checked to see if there were any stations with Winmor capability near me, and see that one is very close, in Mauritius, and there are a few more in southern Africa.

After opening a winmor session, there is not too much to set up — it is mainly a matter of telling the program which sound card to use. If you have used your soundcard to operate other digital modes, this should be old hat. Similarly, radio settings are the same as you would use for sound mode psk31: you will be in USB mode and want to set the power to max and mike gain so that you get the desired power output (in my case, 50W), with no ALC deflection.
Now, I have to admit that I don’t have this working. I have to believe that I am easily within range of the Mauritian station, and I think I have everything setup correctly, but either the station is not in service or I am overlooking something on my end. If I get this working, I’ll post a comment, below. [yes — I got it working; see the comments. Briefly: it was set up right, just had to try another server.]
A note on laptop docking stations
To make this whole thing work, I needed a lot of USB connections: usb-to-serial converters to talk to the PK232, radio CAT control, and to provide PTT for the rigblaster NOMIC, and one for an external sound card. I went with an external sound card because this laptop has one four-segment 3.5mm combination plug located near the front. It would have been a pain to break out the mic input and one of the line output channels, plus the placement is awkward. In most cases, however, you could just use the computer’s built-in sound card and save a USB port. I should mention that the usb sound card that I used was not high-end, I think it was about $8 in a blister pack at Microland. You could also save a USB port by using VOX circuit to trigger the mike rather than hardwired PTT, but I was worried about latency, and wanted to eliminate that issue for troubleshooting purposes.
I always rest my laptops on a docking station (port replicator) to save wear and tear on the laptop connectors. One important thing I discovered, however, is that when mains power goes, so do the ports on the docking station. One option is to plug into backup power — a UPS would suffice if you have a backup generator that kicks in shortly after loss of power. The only concern there would be the potential for the UPS to put out RF noise. The other alternative would be to plug all the USBs into the laptop directly. If the laptop does not have enough USB ports, a USB port hub could be used. I had thought that there might be throughput problems using such a hub, but so far that solution is working for me.
PSKMail: A third option?
PSKmail looks promising in design, but the project is nowhere as neatly packaged or mature as winlink. PSKmail is a system that allows various forms of internet access over a radio link, sending and receiving mail from a POP3 client, for example, but pulling down the text of webpages, sending tweets, and passing APRS messages. The project is not wedded to a particular mode, and links can be made on top of modes such as PSK500 or THROB. It is also designed to fall back from higher to lower throughput depending on conditions.
It sounds great, but getting started involves a steep and confusing learning curve, starting with the PSKmail website. The PSKmail client runs in a java virtual environment, so a first step would be to install the current version of java runtime environment on your laptop. In my case, automatic installation did not work –the program complained that it could not find a path to java, and indeed, I could not invoke java from the command line. Manually deleting the remnants of the previous Java RTE and installing fresh fixed the situation.
There are two versions of PSKmail, version 1 uses FLdigi as a modem, whereas version 2 has a built-in modem. On the PSKmail website’s download page, however, version 2 is flagged as beta. Since I already had FLdigi up and running on my computer, I went with version 1.

Documentation of PSKmail could be better, particularly descriptions on the web, which I found difficult to read. There are pdf manuals on the pskmail website, and while they do not correspond precisely to the version numbers of the releases now available, they are probably the best resource available.
There are a lot of parameters to tweak, and I ended up doing a fair amount of guessing. After trying to work it out, I took a look at available server stations near me, and tried the one in South Africa a few times, with no response.
At this point, I am inclined to put PSKmail on hold until I have a chance to try it in Europe, where there are more potential active hosts. Again, if anyone has had experience getting this working, I would love to hear about it.
Winmor working – A couple days after I posted this initially, I got the winmor mode to work without changing any of my settings, so I guess it was setup correctly to start with. I checked channel selection and had predictions for excellent conditions to Mauritius on 40m, 30m, and 20m. I tried them, but no response. Then, I tried ZS1RS about 3000 km away on 20m, and got a response burst immediately. The connection was not pristine — the “X” in the software TNC “scope” view was not sharp, but the connection held up enough for me to check mail. I tried the connection using receiving bandwidth of 1600hz and 500hz, and both received signals looked the same width to me. Winmor is adaptive, and I think it throttled back the speed/bandwidth to match conditions. According to the status text in the receive frame, I was receiving “2CAR 4FSK”, which I presume means two carrier quadrature frequency shift keying. In any event it worked despite a path reliability estimate of 34 and path quality estimate of 37. Perhaps those estimates are a little low given that I have a hexbeam, so a bit more gain and off-axis rejection. So, three boxes are checked for email over radio: Ssatellite/APRS, HF/pactor, and HF/winmor. The jury is still out on pskMail. If I get that working, I’ll post below.