SCSmail using Robust Packet

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.

Winlink using Robust Packet

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.

Robust Packet Radio

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.

Propellor on Packet

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...

Flummoxed!

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!

Braap analysis

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.

PIC TNC problem

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.

PIC16F88 TNC

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.

Packet lives!

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!

NASA seeks help tracking satellite

NASA has asked amateur radio operators for help to determine if a recently launched satellite is operating. The NanoSail-D satellite was ejected automatically from the Fast Affordable Scientific and Technology Satellite, FASTSAT on Wednesday, January 19. NASA needs reports of the beacon telemetry to determine if it is operating correctly. The beacon signal is on 437.270MHz using standard AX.25 packet so APRS and packet radio operators with 70cm capability should be able to receive it.

Predictions for the satellite can be found here. Reception reports can be submitted here. Full text of the NASA press release here.

DSP TNC

The winds of economic change are starting to have an effect on our online business. Because of that I am spending a lot more time on the computer trying to maintain our search engine positions and think of new revenue streams, with the consequence that I have less time or enthusiasm for blogging and other radio-related activities.

The only noteworthy item of radio news at G4ILO has been the acquisition of an SCS Tracker / DSP TNC for HF APRS packet. It is shown in the picture sitting atop my K2. When I find the time, I will write a review of this TNC for my main (non-blog) website. For the time being, all I will say is that I did a side by side comparison with the best of the PC sound card decoders and it was very quickly apparent that the SCS TNC decoded many stations the sound card software didn't. Considering what it cost, I'd have been very disappointed if it hadn't.

Krun

I spent a couple of hours this morning writing a little program using Lazarus / Free Pascal called krun. I will use it to run certain ham radio programs that I use with my Elecraft K3, hence the name beginning with K like my other Elecraft-related programs. In principle though it could be used with other radios, if their command language uses only printable characters.

What krun does is connect to the radio using the serial port and send a sequence of CAT commands to it. It will then run a specified program. It waits in the background until the specified program is finished and can then (optionally) send another sequence of commands to the radio before closing. The com port, baud rate, command sequences and path to the program you want to run are all specified on the command line.

The main reason for writing krun was to facilitate the use of packet radio software with the K3. The SV2AGW Packet Engine doesn't support CAT at all so it can't set the K3 into the right mode for packet operation. For VHF packet you must use FM, but with the transmit audio coming from the line input. It's hard to remember to switch the audio to line input before using packet and then remember to switch it back again for normal phone operation afterwards, so I often ended up transmitting a signal with no modulation. krun should prevent that. As a bonus it can set the frequency, mode and power level as well, so setting up for packet is almost a one-click operation.

I haven't made krun available on the website as it takes time to document and upload it and it probably won't be of use to very many people. But I may get round to it eventually, if anyone expresses a need for it.

Success, finally (I think)

I hope I'm not speaking too soon, but I think I finally have a working APRS IGate running on the Eee PC! After recompiling soundmodem to cure an apparent problem with the audio, as I wrote yesterday, I ended up with a worse problem: the diagnostic 'scope display froze when I used it. I was on the point of giving up, but on the basis of "nothing ventured, nothing gained" I ran the soundmodem software anyway, started Xastir and lo and behold, received a position beacon from my VX-8E!

There was still a lot of Googling, tinkering and tearing out of hair to get from there to where I am now, and I probably can't even remember half of it. I won't even start to describe my abortive attempt to set up aprsd to work as a gateway without the mapping interface of xastir which I don't like very much. If any aprsd wizards read this and would like to offer their advice I'd still like to try it, though.

One problem I noticed when using soundmodem as a kernel mode driver (which isn't necessary for xastir, but is for aprsd) was that at start-up it spewed out a long burst of what sounded like packet but actually wasn't. Google (however did we manage without it?) turned up a few snippets about this, with the generic advice that soundmodem was being treated as a network device and you needed to stop your network daemons binding with address 0.0.0.0. This was Greek to me. I was hoping for help along the lines of "click here, uncheck that check box" and so on. Eventually I discovered that the rogue daemon was the avahi-daemon service. In Ubuntu you can disable it from System / Administration / Services, then restart and no long transmission when soundmodem starts. It's simple when you know how!

Next I found that APRS messages addressed to my VX-8E (G4ILO-7) and received by xastir were not being transmitted over the air so it could receive them. I had made all the necessary settings, or so it appeared, but there is an additional step: you have to create a file in $HOME/.xastir/data called nws-stations.txt containing a list of calls whose messages you wish to send over the air. The first time I tried it, it didn't seem to work, and I posted a question about this on the xastir mailing list. The post was spotted by John, EI7IG, who sent me an APRS message that appeared on the VX-8E! Why it didn't work the first time I have no idea.

I think everything is now working as it should be. I'm using my FT-817ND on the RF side, for the simple reason that I already have the cabling for it. I'll probably try using my TH-F7E later on, but I don't have the necessary cabling for it.

So now I can be tracked as I move about the local area, and can send and receive text messages via amateur radio. I've already had a few exchanges with EI7IG and I can tell you, I wish Yaesu had implemented predictive text on the VX-8E! If you have APRS too please send a message to G4ILO-7 to say hello. But check my current location page first to see if G4ILO-7 is shown, because APRS text messages aren't stored and sent later if the recipient's current location isn't known.

Eee I'm getting nowhere

Developments on the APRS front have been moving on faster than I can write about them. A couple of days ago I had an email from someone who was running an APRS IGate on an Asus router. I thought this was a good idea - better and more economical than leaving a PC on all the time - but one to consider for some time in the future. Then I remembered that I had an Asus Eee PC 2G Surf sitting unused on a shelf. If I could install the Linux equivalent of UI-View, Xastir, on this, I would have a standalone low power consumption APRS IGate at no extra cost!

The first thing I did was install Xastir-Eebuntu 3.0 from the live CD available in the Xastir Wiki to the Eee PC. It was time to vape the Xandros OS that came with the Eee PC as it was too old to run the latest ham software and failed with errors when many of them tried to use the soundcard anyway.

Because I don't have a TNC I needed soundmodem, which is the Linux equivalent of the SV2AGW Packet Engine. I downloaded that from the Ubuntu repository and then configured it according to the excellent HowTo: SoundModem instructions in the Xastir wiki. Xastir worked just fine, and I could even hear what sounded like packet coming out of the speaker. But no matter how I adjusted the input audio levels I could not decode a single packet transmitted by my VX-8 radio.

Eventually I found that the soundmodem configuration utility has a diagnostic tool. When using the oscilloscope I saw horizontal lines in the waveform - exactly the problem described here and shown in the screenshot on the right.

While wondering what to do about that I had an email from Gareth, GW4KJW, who suggested running UI-View32 under wine, the Linux Windows emulator. This seemed like a good idea, so I installed wine from the Ubuntu reporitory and then extracted the AGWPE archive into a folder and ran it. This appeared to work OK. I then installed UI-View32 from its installer. Ui-View ran, but the map display went black a fraction of a second after the map was displayed. I also got a run-time error message when trying to load a different map.

After more Googling I found that this problem had been encountered before. I tried the recommended solution of downloading and running the winetricks script. This worked, after installing some CAB extractor utility it needed, and UI-View looked fine. But it still did not decode any packets.

Using the AGWPE soundcard test utility I found that audio was being received by the software. However there was a delay of a few seconds between changing the audio level and seeing a response on the oscilloscope display. Presumably some delay was occuring getting the audio from Linux to wine to AGWPE. Perhaps the Eee PC is just too underpowered for this application. The audio looked normal - no horizontal lines - but I could not get anything to decode, so I decided to give Xastir one more try.

First I had to fix the problem with the breaks in the audio. I downloaded the source code for soundmodem (version 0.14), and after downloading and installing a couple of libraries I was able to compile the source code. However when running the diagnostic tool I noticed that the oscilloscope display froze after a second or two. Thinking it was just a glitch, I went ahead anyway and made the changes mentioned in the linux.hams posting mentioned above. This changes the sample rate from 9600Hz (which soundmodem tries to use and which is probably not supported by the Eee PC hardware) to 11025Hz. I then recompiled and tried again. Unfortunately the display still freezes, so I am no further forward.

If you ever wondered why hams who use Linux are hardly ever on the air, I think you have here a very good example of the reason! I suppose the next stage is to try and find some appropriate groups to post the above findings to in the hope that someone more knowledgeable than me will have the answer. But it's all so time-consuming and frustrating that I'm running out of enthusiasm.

G4ILO takes a walk

My new Yaesu VX-8E arrived this morning. The VX-8E is the European version of the VX-8R, apparently. I ordered the GPS unit plus the adapter for mounting it on the radio, and the drop-in charger for convenience. Got a good price for the package from Chris at Martin Lynch and Son, and he threw in the shipping for free.

The method of mounting the GPS on the radio looks a bit Heath Robinson, but I don't normally use a speaker-mic so it seemed like the best option. If I'm out walking I usually put the radio in a top pocket or clipped to the right shoulder strap of my rucksack which gives it a good, clear view of the sky.

The battery charged up in about two and a half hours, just as claimed, so after lunch I was able to sit down with the radio and start working through the manual. I skipped quickly to the APRS configuration section to get that all set up. The GPS was working, so I sent a beacon, heard it digipeated back by my FT-817, and saw G4ILO-7 appear on the UI-View32 display.


Now it was time to go for a walk. I set the beacon interval to 2 minutes and beaconing to AUTO, popped the VX-8E into my jacket pocket and went for a stroll around town. I was using 5W to the stock rubber duck antenna. As the map from aprs.fi shows, only about three position reports were missed: two as I was walking in the park down near the river with a steep bank between me and the home QTH, and one as I was walking along Crown Street.

My wife Olga was watching my progress live on the computer and opened the front door just as I walked up the drive! She was very impressed by this demonstration of how ham radio can be useful. It would be nice if she was impressed enough to get her own license because I would find it quite useful to track her whereabouts when she disappears to the shops for hours, but that's just wishful thinking!

I'm impressed with the performance of the GPS. It works fine in my jacket pocket, unlike the iFinder GO2 walker's GPS I have which needs to be in a prominent position to get a fix from the satellites. The VX-8 even gets a fix from inside my shack.

I tried sending a text message, which popped up on the computer screen. I was able to answer it once I was back home. :) Some people may wonder "why bother, when you have text messaging on your mobile phone" to which I can only answer "why use ham radio at all then?" I think it is great that you can do all this using an amateur system, and I wish that it were possible to subscribe to ham radio related information such as propagation or DX alerts using APRS messaging.

If you are on APRS yourself I'd love to hear from you by APRS message to G4ILO-7 telling me where you are and what you're using. (But check to see if G4ILO-7 is on-air first, or your message won't reach me.)

IGate issues

Ever since I was a child, I have been fascinated by maps. My attempt to receive signals from satellites led to my finding out more about Automatic Packet Reporting System (APRS) and I became interested in trying its position tracking capabilites, as well as the potential it offers for ham radio-based text messaging. So I'm currently awaiting the arrival (hopefully today) of a Yaesu FT-8R APRS-capable HT in my shack.

While I was waiting I decided to set up an APRS Internet Gateway or IGate, so that my position when I'm out and about with the VX-8R can be monitored on sites like findu.com, aprs.fi and OpenAPRS. This wasn't something I wanted to tie up the Elecraft K3 and DB6NT transverter doing, so I set up my FT-817ND to act as my APRS receiver, using my computer's integrated sound card (I have a separate SB Live 24 card for use with the K3.) For the IGate antenna, I reinstalled in the attic my 2m Slim Jim. However, last night while making some PSK31 contacts on 80m with the K3 I noticed that my IMD Meter was showing a poor signal again.

For some reason that I do not understand, having the Slim Jim connected to my station upsets the K3 and makes it produce a distorted signal. At the time, I put it down to having too many antennas in not enough space and I took the Slim Jim down. But now I need it. Disconnecting the Slim Jim from the FT-817 cures the bad signal from the K3, as does disconnecting the FT-817 from the shack power supply. It was a short step from this to finding that operating the FT-817 from its own independent power supply rather than the Diamond GSV-3000 that also powers the K3 leaves the signal clean. At least, it does on 80m. I haven't tested on any other bands yet. Unfortunately the only other power supply I have that's suitable is a small switcher, so now I have a clean PSK31 signal but warbly noises wandering around the HF bands.

The other problem related to the IGate that I haven't yet solved is what software to use for it. Like most newcomers to APRS (I guess) I started off with UI-View32. This is quite a nice program that displays APRS position reports on a map, offers APRS messaging capability and also has a built-in IGate. However, it is no longer being developed or supported as its author is a silent key. Also I preferred a standalone IGate that I could leave running all the time without the overhead of position tracking on a map.

The only alternative I could find is AGWUIDigi, from the same author as the AGW Packet Engine that I use. I think this works, but it appears not to post its own position beacons to the Internet, so when I run it my IGate does not appear on any of the maps. This is a significant limitation to me, as I want my station to be shown so that others can see that there is APRS activity in my area, and hopefully encourage more use of this interesting mode. Perhaps it's a simple configuration issue, but I can't see it.

Signals from space

The September issue of the RSGB's excellent RadCom was awaiting me on return from holiday. It contained an article about two new atmospheric research micro-satellites, Castor and Pollux, which transmit telemetry using AX.25 packet in the 2m band. This piqued my interest enough to try to have a go at receiving them.

The tiny satellites consist of two 19in. diameter spheres separated by an insulator, which form the two halves of the 2m antenna. There is a super photograph of the two satellites, taken shortly after they were launched at the end of July from the Space Shuttle Endeavour, which can be found on many of the websites that carry information about the launch.

My first problem was to find some way to decode 2m packet. I used to have a copy of MixW, but I had not used it for a couple of years and when I tried, it crashed immediately after start-up. I deleted it and tried installing a new copy but it came up in German! I also realised that I no longer had the registration code for it. So I decided to look for another solution.

I found it at SV2AGW's website. I installed the AGW Packet Engine (AGWPE) and then AGWMonitor to receive the telemetry. Setting up the Packet Engine to receive packet using the sound card is not very intuitive, and in fact I gave up the first time and spent another couple of hours trying to find a backup copy of my MixW installation, without success. Then I found an excellent step-by-step guide to setting up AGWPE with a sound card by KC2RLM that got me going. AGWMonitor requires AGWPE, and the trick is to put it into the Startup Programs option of AGWPE so that the monitor is launched directly after you start the engine.

I used the N2YO Live Real Time Satellite Tracking website to find out when the satellites are visible from my QTH. This shows that they currently pass over very late at night and during the small hours of the morning, when I am asleep, so I left everything on overnight to see what I could receive. The first time, all I got were a number of packets from the International Space Station, RS0ISS.

This morning, I received one packet from Pollux-1 and one from Castor-1 (which confusingly identifies itself as KD4HBO-1 in the packet header.) Just for fun, I decoded the packets using the telemetry decoders written by Mike Rupprecht, DK3WN - though to be honest, the information didn't mean anything to me. Captured telemetry should be sent to ande@juno.nrl.navy.mil and QSL cards will be sent to anyone who submits data.

I also received many more packets from the ISS, which uses the same frequency of 145.825MHz. The result of this is that I have now become interested in trying to make packet radio contacts through the ISS digipeater!

What a great hobby this is! There seems to be no limit to the different things you can try to do with amateur radio!