Wednesday, May 15, 2013

Playing with APRS

APRS has seemed to be the most wide spread use of VHF packet mode for many years now.  I have been on the fringe of this system by having a mobile tracker in my car off and on for the last 10 years.  N1ZZZ-9 has had a nice run across the US several times, and in the areas close to my various home QTH over the years.   These days with a new car, and a XYL who isn't too keen on having it's finish marred by an external antenna, the Kenwood TH-7 has degraded from a mag-mount antenna to a rubber duckie.  Of course the rubber duckie antenna isn't very good at getting the signal out.

For the last two years or so, I have also had a portable station, N1ZZZ-7, on the air in the form of a Yaesu VX-8.  Again, when walking around with an H-t on your belt and a rubber duckie, your signal isn't going to get too far, but it sometimes manages to get my signal out to digipeaters.

I have been fortunate here in the Wilkes-Barre, PA area.  While standard packet is almost non-existent, the  APRS system is very strong, especially along the I-81 corridor.  There are several Digipeaters as well as a capable I-Gate to send the signals into the Internet for all to see.

What I have never done in all of these years, has been using APRS in it's most interesting incarnation, and that is with a fixed station, with a "real" TNC, and a mapping display to show where all of these beacons are.

This past week, I finally found a program that suited my needs and worked with the equipment I already had.  The program was APRSIS32.  The program was an easy download and installed quickly.  The program connected to the APRS servers via the WiFi port in my computer and immediately started to download maps and place beacons on the screen through the IGates.  The next step was getting my GPS to talk to the program.

  I have a Garmin GLO GNSS receiver that connects via a Bluetooth link.  This little receiver uses both the American military's GPS system and the Russian governments GLONASS constellation.  Getting this device to talk to the APRSIC32 program proved to be a very easy.  I turned on the GLO and enabled the GPS via Bluetooth in the program and it immediately found a fix.  Not only did the program display my position both in Lat/Long, but also gave me a grid locator.  The station's speed (0 at this time) is also prominently displayed on the screen.  Most interesting to me was that the program also displayed the number and status of satellites in both the GLONASS and GPS systems.  Even with my GLO on my desk near the window,  I am getting better than 20 satellites in the list.  These satellites' geographic position are also displayed on the screen as they float on by.

Getting my Kantronics 9612 TNC hooked up proved to me more difficult.  The TNC needs to be in KISS mode, but I also use it for normal packet, so I can't get the 9612 "stuck" in that mode.  I needed the program to start the 9612 in KISS mode, and then return it to Terminal mode when the program exited.  Kantronics TNC's are a bit fussy in my experience and this proved to be no different.   I knew that the computer was able to talk to the modem because I was able to use the AirMail dumb terminal was able to get me command prompts, but the APRSIC32 was not able to find it properly.  While the program claimed that the radio port was active, it would not key the TNC or get any packets from the radio. 

The problem is in the XML script located in the local folder where APRSIC32 is situated.  This is a far cry from the plug-and-play software that is the norm today.  To fix this problem, I had to do some internet research.  The program's wiki talks about the lines for a Kantronics KPC, but not the 9612 specifically.  In the interest of sharing the data, I will post the script from my XML file here so that anyone who needs it can cut and paste and get it working.

<RFPort Name="KAM">
<OpenCmd>XFLOW ON!!0</OpenCmd>
<OpenCmd>FULLDUP OFF</OpenCmd>
<OpenCmd>INT KISS!!0</OpenCmd>
<CloseCmd>TC 1!TS 1</CloseCmd>
<CloseCmd>TN 2,0!TN 2,0</CloseCmd>

A few notes:  1) the name of the port is up to you (KAM) in this case.  Your COMM port will also vary depending on your configuration.  Since I am using a Serial to USB dongle, I have a rather high COM4 number.  Most native Serial ports will be 1 or 2.    The big difference between the KPC and the 9612 are the commands to get into KISS mode.  For the 9612 the commands are "Int KISS" and then "reset"  The difference between the lines "reset" and "restart" escaped my notice the first time, so be careful.

After my script was working, I was able to get the KAM to start putting stations on the map.  I checked this by disabling the Internet connection for a bit and clearing the station list.  Eventually the digipeaters starting giving me data that got the stations through my 2 meter rig and 9612 and to the software.

The next stage of this will be getting a SCS tracker online with Robust Packet on 30 meters to pull in the long-haul stations.  I just have to see if I can run two USB modems without things getting all sideways.


Monday, May 13, 2013

Pactor II verses Clover II

In the early 1990's DSP chips finally became financially feasible and two DSP based, phase-shifted modulation modes became available to hams.  Ham developers in the USA and Germany separately developed two HF digital modes that combined high data transfer speeds while remaining fairly robust and capable of maintaining point-to-point links over the HF radio spectrum.

The two modes were Clover and Pactor II.  Implementation of the phase shift modulation was slightly, different, but these two modes were generally the same speed and claimed nearly equal robustness in the face of low S/N ratios.

I have always been a big fan of both of these modes and have used both since about 2003.  These modes have be upgraded over the years, but the version two of these modes have always been very good for keyboard links. 

Recently I was on the air with Pactor II with VE1XL.  Conditions were poor with large fades in the path.  Even the robust Pactor II was having some trouble moving data.  It was still good enough for keyboard work, but the fades caused several error messages going back and forth as the data packets did not make it.  Given that these were adverse conditions, I suggested to VE1XL that it would be a nice opportunity to test Clover and Pactor head to head. 

We ended our Pactor link and switched to our DXP-38 Clover modems.  These are the latest of the Hal Clover II modems and gave the mode the best chance at keeping a link.

We were able to establish the link, but we had trouble with the data blocks.  Unlike Pactor, Clover uses what it calls Clover Control Blocks.  These are sent at a modulation scheme that is the most robust it can muster.  Unfortunately the CCB's modulation is not available for data packets.  This proved to be the deal breaker on this link.  Despite some error packets, the CCB's managed to get through, but as soon as the data packet tried to make it through, it was not able to get there.

Sadly eventually the link failed and we had to go back to Pactor.

So what shall we make of this?  While I still find Clover more fun to operate due primarily to the fact that it has a more effective semi-duplex paradigm, and the ability to exchange station data on both ends of the link, it still needs more power to keep the S/N ratios up to the point where data can make it through.  Pactor is a superior poor link mode, and this is a common consensus.