Again, this is not intended to be a polemical discussion. If you have suggestions about how I might improve my testing methods, I would appreciate your comments.
I enjoy MFSK16
Ever since Nino and Muirray brought out Stream, their software for communicating via MFSK16, this has been my favorite mode. I much prefer it to telephony. Most younger hams learn typing as children and the speed of MFSK16 is appropriate for an experienced typist. I find it to be a good balance between speed, bandwidth, and robustness to ionospheric insults. In my mind, except for contesting, it is the modern RTTY.
When MixW incorporated MFSK16 I switched to that program. When Patrick developed his Reed Solomon mode ID code in Multipsk, I switched to his program and I began working hams for whom I was their first MFSK16 QSO. They were running Digital Master 780 or Multipsk and recognized the mode from the RSID. I consider RSID to be a significant contribution to amateur digital communication.
I had always assumed that all MFSK16 software packages were about the same in sensitivity until someone in a QSO said I needed a more sensitive software program. So I decided to collect some data. Here it is:
But MFSK16 was designed by Murray Greenman, ZL1BPU, for poor ionospheric conditions. How do the packages do when we simulate this environment?
How were the tests done?
- A 1400 character text file of ham calls and five digit number groups was created.
- The text file was fed into Stream to generate a seven minute wave file. The lowest audio frequency was set to 1500 hz.
- Virtual Audio Cable was used for all audio connections so the testing is independent of the quality of any physical sound card. An attempt was made to avoid any real time audio file format changes.
- The recording and playback was done in Audacity.
- PathSim, from AE4JY, requires a 16 bit, 8 khz mono wave file as its input and exports a similar file after adding noise to the signal.
- The Stream 11 khz MFSK16 signal file was loaded into Audacity and resampled to convert it to 8 khz for PathSim and then the PathSim output files were resampled to convert them to 11.025 khz sampling rate with Audacity's high-quality sinc interpolation with triangle high-quality dither.
- As each program was used, I set that process to "High Priority" in Windows XP. I saw no evidence that the performance was limited by CPU availability for either the MFSK16 program or Audacity.
- AFC was used in a trial run with a high SNR file to check the tuning and then turned off when data was collected.
- Errors in the text would contain characters that RttyCompare could not analyze. Consequently, the editor function in MorseCat was used to remove non - Baudot characters from the received text files before pasting into RttyCompare.
- The text resulting from the tests was pasted into RttyCompare from VE3NEA which compares the received text to the expected text and calculates the number of errors. Alex's work with RttyCompare essentially drew a map showing how to do this experiment. His data also called my attention to TrueTTY.
Digital Master 780
IZ8BLY Stream 1.2
I would be interested in how I might modify my procedure to gain more meaningful results. Also, these results include no attempt to simulate the many insults a signal suffers during its trip through the ionosphere. The data from this experiment had less scatter than the analogous experiment with RTTY signals, presumably because of the absence of the profound effect of stochastic figures/letters shift in RTTY.
So which MFSK16 software should I use?
There are many reasons to choose a package other than sensitivity. One of the most important is how well the AFC functions and these tests don't investigate this factor. Also, I am hesitant to use a program for transmitting that does not incorporate the RSID function so that new hams can recognize the MFSK16 signal. But I have just registered a copy of TrueTTY and I will use it as a second receive modem. The improvement in reception it offer in my hands is significant.