HF Packet Radio AX.25 vs FX.25 Comparison Test

INTRODUCTION

This test was conducted to compare the relative performance of traditional AX.25 packet with the enhanced form known as "FX.25".

Normal AX.25 packet radio data transmission has no form of error recovery. When a packet is received, a 16-bit CRC check is done at the receiving end.  This check determines if the packet contains data errors introduced by noise and interference in the radio transmission process.

If the packet does have error(s), the receiving system discards the entire packet. If the receiving station is "connected" with the transmitting station in a two-way relationship, the receiving station can send a request for re-transmission of the entire data packet to the sending station.

APRS use of packet data normally is a one-way one-to-many broadcast mode of transmission. The receiving station(s) normally do not transmit back to the sender.  They can only ignore a defective received packet, with no way to "fix" it.

FX.25 is a recent addition to the AX.25 protocol. It adds a block of error-correcting code to the basic AX.25 packet that allows the receiving station to repair defective packets WITHOUT having to ask the sending station to retry sending the data. For the enhancement to work, both the sending and receiving stations need to able to encode/decode the enhanced packet. If the receiving station does not support FX.25, the packet will be decoded as a normal AX.25 packet, with no way to fix errors.

Normal AX.25 packet data works quite well on VHF/FM channels that are mostly noise-free.  AX.25 packet transmission has always been a terrible mode for HF transmission. HF radio channels almost always have noise, static crashes, pops of noise from electrical devices, selective fading, multi-path distortion, etc. The error rate is  much higher than on VHF. Stations often have to resend the same packet several times before the receiving station receives it successfully.  In one-way broadcast transmissions like APRS, the "loss rate" of transmitted packets is far higher than on VHF/FM.  

BACKGROUND & TEST SETUP

This over-the-air experiment was conducted to determine how much more reliable FX.25 transmission was compared to traditional AX.25.

At least two software-based sound card "soft TNCs" now have the ability to encode and decode the enhanced FX.25 packet format:  The "UZ7HO Soundmodem" and "DireWolf".

• The Soundmodem is a strictly Windows-based application with a nice graphical interface, a received-data monitor screen, and a waterfall display.  Most common settings in the Soundmodem can be made through it's graphical interface. More options are available by editing an extensive configuration file "soundmodem.ini".
   
• DireWolf is a command-line based-program that runs in the background with no visible display. It is available in versions for both Windows and Linux. Unlike the Soundmodem that depends on external applications, DireWolf can operate stand-alone as an APRS "Igate" (Internet gateway), packet digipeater, or APRS transmit-only "tracker" (reading data from a GPS receiver and formatting it for APRS transmission).  It can also function as "justs a modem" linked to external applications. ALL settings are determined by editing it's configuration file with a text editor.

The receive setup was my usual 60-meter APRS igate setup using a Yaesu FT-891 and the UZ7HO Soundmodem configured to auto-receive either classic AX.25 packets or FX.25. The receive antenna is a pair of MFJ 60-meter "hamsticks" configured as a mini-dipole about 10 feet (3 meters) above the ground. This yields excellent high-angle ("NVIS") radiation, ideal for short-haul in-state communications at the lower HF frequencies.

60-meters Ham Stick NVIS Mini-Dipole

The mobile transmit platform was my VW Jetta TDI diesel. I ran two instances of UIview linked to two instances of the UZ7HO Soundmodem on my Panasonic Toughbook CF-51 mobile laptop.  One UIview/Soundmodem pairing was beaconing APRS posits as WA8LMF-2 on AX.25. The other was beaconing as WA8LMF-3 on FX.25. Both instances were coupled into the same home-brew tone-activated soundcard interface. The interface fed the 6-pin mini-DIN data port of another Yaesu FT-891 fed into another MFJ 60-meter ham stick mounted on the left-rear of the car with a Breedlove mini split-ball mount.

THE ACTUAL TESTS

The tests were conducted on 60 meters "Channel 5" (5403.5 MHz USB) during a drive from East Lansing, MI to Berrien Springs, MI for a ham swapmeet. The drive is about 180 miles (290 km) each way.  The drive started on Friday afternoon at 3:30 local, meaning full daylight propagation on 60 meters. At the mid-point of the trip, I stopped to spend the night at my sisters's farm just east of Kalamazoo, MI.   The following Saturday morning, I resumed the trip, departing at 5:00 AM local to reach the ham fest venue by 7:00 AM to setup before the opening at 8:00 AM. This half of the trip was in darkness.

Maps 1 &2 below show the tracks for the entire outbound trip- both Friday afternoon and early Saturday. They were captured from APRS.fi. Propagation favored the Friday afternoon part of the drive. When I resumed Saturday morning at 5:00 AM, 60M was dead (or the band was way too long for my home station to hear my mobile). I started seeing the beacons on APRS.fi around 8:00 AM - an hour after I arrived at the swapmeet site.  Note that the points inside the Lansing-area freeway beltway are direct local ground-wave reception (not HF skywave). [The next two maps, 3 & 4, show the return trip.]

1 - East Lansing to Berrien Springs Outbound  -  AX.25       WA8LMF-2 from APRS.fi

2 - East Lansing to Berrien Springs Outbound  -  FX.25       WA8LMF-3 from APRS.fi

After the ham fest ended around noon, I began the return trip entirely in daylight, starting around 12:30 PM. I stopped at my sister's farm again for several hours starting about 2:30 PM before resuming again at 5 PM. I arrived home about 7:15 PM Saturday evening. 

At the time of my departure around mid-day, propagation was NOT favoring my path.  Only one position report got through on AX.25 while several got through on FX.25 before I reached the metro Kalamazoo area. Later in the afternoon, after my layover at my sister's farm, propagation improved. Both modes showed more successes, though FX.25 was always superior. The jog south to Portage was when I got off the Interstate in Kalamazoo for lunch and the cheapest diesel in Michigan.

3 - Berrien Springs-to-East Lansing Return  -  AX.25   

4 - Berrien Springs-to-East Lansing Return  -  FX.25        WA8LMF-3 from APRS.fi

CONCLUSION

While the FX.25 mode did produce more successful reports, the improvement was modest. The optimized-for-HF modes like MFSK and VARA had nearly TEN TIMES as many successes as 300-baud HF AX.25. in previous tests. earlier this year.

The difference between AX.25 and FX.25 may be less dramatic for another reason. The UZ7HO Soundcard TNC/modem has another unusual feature: It actually tries to repair defective AX.25 packets with a method that is completely unrelated to FX.25.

When a received packet fails it's CRC, the Soundmodem tries inverting one bit of the packet at a time, and computes the CRC again. If the damaged packet has only one wrong bit in it, this "bit-flipping" brute-force trial-and-error process will ultimately result in a CRC that matches. If a packet has a length of 100 bytes, this will result in up to 800  bit-flip-and-test  operations.  Obviously, this isn't a problem for fast modern computers, but could be for low-powered micro-controllers or classic hardware TNCs based on 8-bit 2-MHz Z-80 processors.

The result of this feature is AX.25 processed by the Soundmodem comes out looking "less bad" compared to FX.25,  than hardware or software TNCs without this feature.