HF APRS - VARA vs MFSK vs OFDM Shootout!

Introduction

Having demonstrated that the VARA high-performance data modem was dramatically superior to classic AX.25 packet for APRS on HF, I am now attempting to compare the VARA-HF modem to both MFSK-16 and OFDM-500 modes generated by FLdigi.   [See previous results of the AX.25 vs VARA test here:  HF APRS Over VARA Modem ]

The test setup in the car uses VARA linked to one instance of UIview, FLdigi in MFSK-16 mode linked to a second instance of UIview, and a second copy of FLdigi in OFDM-500 mode linked to a third copy of UIview.

[Multiple copies of UIview can run on the same computer at the same time, as long as they are all installed in different folders.]

UIview's  KISS-over-serial outputs are bridged to the three modems (all of which only do KISS-over-TCPIP) with three stacks of the Eterlogic "VSPE" (Virtual Serial Ports Emulator) utility.  A separate VSPE "widget" splits the incoming data from the same GPS receiver on COM4,  so all copies of UIview can use it from multiple "COM5" ports at the same time.

Ever since Windows Vista, it has been possible for two or more programs to access sound devices simultaneously. In this setup, the VARA modem and both copies of FLdigi are accessing the same sound system at the same time.
    In the road tests, all three modems are linked to a Behringer UCA-202 USB "sound card" connected to one of my homebrew tone-activated sound card interfaces.  These interfaces DO NOT require a serial port, USB port or CAT control to key the radio transmit PTT line. The net result is that the same sound system & interface, same radio (Yaesu FT-891) and same mobile antenna (60 meter MFJ monoband "Ham Stick") are used on all modes.

[Although "Ham Stick"-type mobile whips are made by several manufacturers, MFJ appears to be the only one offering this kind of antenna for the 60-meter band.]

Transmit power of the 100-watt FT-891 was set to around 30 watts output to assure fully-linear low-distortion handling of the complex waveforms of OFDM and VARA.

The receiving system in Haslett, Michigan is another Yaesu FT-891 connected to a horizontal "mini-dipole" made from two more MFJ-1660T "Hamstick" mobile whips. The two whips are combined with an MFJ-347 mini-dipole mount.

[Again, several manufacturers offer this kind of mount for making mini-dipoles from mobile whips. MFJ's version is the only one that isolates both whips from the mast they are mounted on --  a huge advantage in reducing local noise pickup on the lower HF bands.]

A close-up view of the feed-point, showing the MFJ-347 mount and an RF choke creating a balun to isolate the two halves of the dipole from the coax line.  This mount provides two isolated 3/8-inch-24 (standard HF mobile whip stud) sockets and a clamp that fits around standard 1-1/4-inch-diameter TV antenna masting. The coax is the small-diameter Teflon-dielectric/Teflon-jacketed cable normally used on NMO mobile mounts in the UHF and 800-mhz  range. I used it here, not for the low-loss, but for the small diameter that allowed 4 turns to fit through the ferrite torroid choke. (The RF choking effect is proportional to the square of the number of turns through the torroid core- thus I have 16 times the effect of a single pass through the core.)

This is a screen shot of the 1024x758 "XGA" screen of the Toughbook showing the three  instances of UIview and all three modems running.   Note the low CPU loading with all this stuff running at once on a 32-bit 1.5 GHz dual-core Intel "Centrino" CPU on the VARA CPU meter.  I made three copies of the same UIview map, each overlaid with the mode being used -- otherwise it would be impossible to tell what mode each UIview was linked to!

Testing the three modems side-by-side, one thing is already apparent.  For the identical APRS compressed position report and short comment string generated by UIview, MFSK takes about EIGHT times longer to send than VARA.  FLdigi OFDM takes about 3 times as long as VARA.
    It will be interesting to see if the much longer (slower) symbols of MFSK fare better in the real-life world of the lower HF frequencies plagued with multi-path and selective fading distortion, especially in the twilight periods of propagation.
    The test road trip for this project was supposed to be a round-trip drive from the East Lansing, Michigan area to Traverse City, Michigan and back, for an amateur radio swap meet on the 11th of February.  Traverse city is about 150 miles / 240 Km from East Lansing "as the crow flies". The driving (road) distance is about 180 miles / 290 Km. 
    The outbound trip started around 3:30 AM local in order to arrive at the swap around 7:00 AM local to setup my seller's table.

The experiment was disrupted by numerous issues with RFI, electrical noise in the car, and and glitches with the two copies of FLdigi "talking to each other".  The tests in my carport with a 10 dB 50-watt attenuator between the FT-891 and the mobile whip worked perfectly for many hours. (The attenuator was to reduce the overload of my base-station receiver during close-in testing.  It also served to hide the mismatch from the mobile whip de-tuning when parked in the carport. I wanted the radio's power amp to see as closely as possible a pure 50-ohm load, in the interest of reducing distortion while transmitting these complex modulation wave-forms.)

Everything came "unglued" on the road!  FLdigi's receive decoder is so incredibly sensitive that transmitting on MFSK on one instance of FLdigi would cause the other instance to switch from OFDM to MFSK whenever it heard the RSID of the first instance.  I didn't realize for an hour that I was beaconing MFSK twice instead of MFSK followed by OFDM. 

I'm still uncertain if the problem was sneak low-level audio paths in the computer leaking the TX audio back into the RX side, or unwanted detection of the transmitted RF.  Later, I realized, you can turn off the receive RSID processing, and LOCK FLdigi to a single transmit mode.

Electrical noise from the car's electrical system caused the serial-port-based PTT keying to lock up repeatedly. Apparently this was due to the DigiRig interface used not having any isolation between the computer and radio sides; i.e. common ground system and ground loops. I lost several hours enroute at rest areas rebooting and  restarting all the programs involved.

The outbound trip was supposed to start with full night-time propagation transitioning to twilight as I arrived.  The return trip was to depart Traverse City around 1:00-2:00 PM, placing most of the drive in full daylight, when signals are weaker, but normally have far less multi-path distortion.

After driving about half-way home, it occurred to me to try my home-brew totally-isolated passive tone-activated interface (that I had been demonstrating at the hamfest) instead. I spend about an hour and a half along the side of route M-115 installing the new interface and then re-configuring all the software involved to use the VOX-like mode of the new interface instead of the "hard-keying" of the serial port RTS mode.  By the time I got everything working, it was twilight , causing most of the return trip to be in darkness again.

The bottom line is that the test was a complete failure!   I will re-attempt this test on the next out-of-town roadtrip to a hamfest later this year.

    From my previous tests, direct ground-wave propagation extends out from the home location about 25 miles / 40 Km. This should not be affected by changes in HF propagation.

Route of the planned trip. The route out at night, and the return trip in the daytime will be the same. Map image from Microsoft MapPoint 2011.

This is a shot of the VSPE stack linking UIview #1-to-VARA, UIview #2-to FLdigi in MFSK mode, and UIview #3 in OFDM mode at the same time. The VSPE  COM4-to-COM5  "splitter" creates multiple virtual "COM5" ports from a single physical COM4.  Data from the GPS receiver attached to COM4 is shared with multiple applications simultaneously connected to "COM5". This includes three copies of UIview, MapPoint, DeLorme Topo 10.0, and "Visual GPS" (a GPS status monitor) at the same time. (The splitter can service up to 8 applications on the same virtual COM port at once.)